Chapter 7
How the records and calculations of WIA-BIO-016 find their place in a Common Technical Document, what data integrity obligations fall on the tools built around the SDK, how to test an implementation against golden vectors, and what a WIA conformance claim can honestly say.
The previous six chapters built up a chain of evidence: a molecule is characterized, its binding is measured, its exposure and effect are modelled, its immunogenicity is triaged, its stability is followed over time, and, for a follow-on product, its similarity to a reference is argued attribute by attribute. None of that evidence has any regulatory value until it is organised into a dossier that an agency can review, and none of the software that produced it can be trusted until it has been tested against known answers. This chapter covers both sides of that last step.
The first half is about the dossier. It explains the Common Technical Document (CTD) structure defined by ICH M4, the quality (CMC) content that a biologic's Module 3 carries, the ICH and agency guidelines that the WIA-BIO-016 specification points to, and the data integrity expectations that apply to any computerised system producing GMP or submission data. The second half is about the software. It shows how to test an implementation of the WIA-BIO-016 SDK and CLI, documents defects that such testing exposes in the version 1.0 source tree, and describes the conformance evidence that the shared WIA annexes ask for. The chapter closes with a boundary that matters more than any of the technical detail: what a WIA conformance certificate may claim, and what it must never be mistaken for.
ICH M4 defines the Common Technical Document, a harmonised layout for marketing applications accepted by the ICH regulatory members. The CTD is a triangle: Module 1 holds region-specific administrative information and is not harmonised; Module 2 holds overviews and summaries; Modules 3, 4 and 5 hold the underlying reports for quality, nonclinical and clinical data respectively. The quality part is described in ICH M4Q, and for a biologic it is usually the largest and most technically dense part of the submission, because for these products the manufacturing process and the product's measured attributes are inseparable.
WIA-BIO-016 §9.2 lists the headings of Module 3.2.S (drug substance) and 3.2.P (drug product). The full M4Q numbering is worth knowing because reviewers navigate by it:
| Section | Content |
|---|---|
| 3.2.S.1 | General information: nomenclature, structure, general properties |
| 3.2.S.2 | Manufacture: manufacturers, process and process controls, control of materials (including cell banks), critical steps and intermediates, process validation, manufacturing process development |
| 3.2.S.3 | Characterisation: elucidation of structure and other characteristics; impurities |
| 3.2.S.4 | Control of drug substance: specification, analytical procedures, validation of procedures, batch analyses, justification of specification |
| 3.2.S.5 – S.7 | Reference standards or materials; container closure system; stability |
| 3.2.P.1 – P.8 | Drug product: description and composition, pharmaceutical development, manufacture, control of excipients, control of drug product, reference standards, container closure, stability |
| 3.2.A | Appendices: facilities and equipment, adventitious agents safety evaluation, novel excipients |
| 3.2.R | Regional information |
Two details from this table are easy to miss when reading the specification alone. First, the specification's list for 3.2.P omits P.4 (control of excipients), which is a heading in its own right. Second, the adventitious agents safety evaluation in 3.2.A.2 is where viral clearance data for a cell-culture-derived product are presented; it is one of the sections a reviewer of a CHO-derived antibody will read most closely, and WIA-BIO-016 has no data type for it.
The specification names three application routes that use this same Module 3 skeleton. In the United States, a new biologic is licensed through a Biologics License Application under section 351(a) of the Public Health Service Act. A biosimilar uses the abbreviated route in section 351(k), created by the Biologics Price Competition and Innovation Act, which relies on a demonstration of biosimilarity to an already licensed reference product rather than a full independent development programme. In the European Union, a Marketing Authorisation Application for a product derived from recombinant DNA technology goes through the centralised procedure of the European Medicines Agency. The quality module for a biosimilar is not thinner than for an originator; if anything it is heavier, because it must carry the comparative analytical data discussed in Chapter 6 in addition to a complete stand-alone quality dossier.
RegulatorySubmission typeWIA-BIO-016 captures the application itself as metadata. The RegulatorySubmission interface carries a pathway, a submission type (ind, bla, maa, amendment, annual-report), an indication, an optional phase, estimated submission and approval dates, and two flags, orphanDrug and fastTrack. The RegulatoryPathway union offers fda-bla, ema-maa, pmda-japan, nmpa-china, biosimilar-351k, accelerated and breakthrough.
That union mixes three different axes. fda-bla and biosimilar-351k are legal routes; pmda-japan and nmpa-china are agencies; accelerated and breakthrough are expedited programmes that attach to an application rather than replace it. A breakthrough-designated antibody is still filed as a BLA. An implementation that needs to answer questions such as "which of our 351(k) programmes also hold an expedited designation" should model agency, route and expedited programmes as separate fields, keeping the WIA enum value for interchange. Regions that the enum does not list, such as Korea's MFDS or Health Canada, need the same kind of extension; the model has no free-text escape hatch, so a local code list is the practical answer.
// Illustrative extension that keeps the WIA value for interchange
interface SubmissionRecord extends RegulatorySubmission {
agency: 'FDA' | 'EMA' | 'PMDA' | 'NMPA' | 'MFDS' | 'HC' | string;
legalBasis?: '351(a)' | '351(k)' | 'centralised' | string;
expeditedPrograms?: Array<'breakthrough' | 'accelerated' | 'fast-track' | 'priority-review' | string>;
sequenceNumber?: string; // eCTD sequence, e.g. "0000"
}Chemistry, Manufacturing and Controls is the part of the dossier that proves the product can be made consistently and controlled adequately. Specification §9.1.2 lists the essentials for drug substance (process description, in-process controls, specifications, stability data) and for drug product (formulation composition, manufacturing process, container closure, stability data). Each of these deserves a sentence of interpretation.
CellCultureParams and PurificationProcess (Chapter 6), but those types hold results, not the parameter ranges that a process description must state.Specification §9.4 lists "typical mAb specifications". They are best read as an example of the shape a release specification takes, not as limits any product must meet. Actual acceptance criteria are product-specific and are justified from the product's own manufacturing history and clinical experience.
| Test (example) | Example criterion from §9.4 | Comment |
|---|---|---|
| Appearance | Clear to slightly opalescent | Maps to StabilityResult.appearance |
| pH | 6.0 ± 0.5 | Set by the formulation, not by a class rule |
| Protein concentration | 95–105% of label claim | Usually by UV A280 with the product's extinction coefficient |
| Purity / size variants | ≥95% monomer, <5% aggregates by SEC | Maps to QualityAttributes.monomer and .aggregates |
| Charge variants | Main peak 60–80% | Highly product-specific; reported as a range with acidic and basic groups |
| Potency | 80–120% of reference | Bioassay relative to an in-house reference standard (3.2.S.5) |
| Endotoxin | <1 EU/mg | Limit is derived from the maximum dose and route |
| Sterility | Pass (USP <71>) | Pharmacopoeial compendial test |
| Bioburden | <10 CFU/mL (pre-sterilization) | In-process limit applied before the sterilizing filtration step |
The table also shows where the WIA model stops. QualityAttributes stores numbers for purity, monomer, aggregates, fragments, charge-variant groups, potency, endotoxin, host cell proteins and residual DNA. It does not store the acceptance criterion, the analytical procedure, the lot number, the test date or who performed the test. A tool that wants to generate batch analysis tables for 3.2.S.4.4 or 3.2.P.5.4 has to add those fields; the next section explains why they are not optional.
Specification §9.3 points to a family of ICH guidelines and §10.1 lists four references: the two agency documents on biosimilars shown below, ICH Q6B, and an FDA 2020 guidance on COVID-19 vaccines, which is not used in this book and is omitted from the table. The table below gives the full titles and the chapters of this book that depend on them. Revision suffixes change over time; always check the current version on the ICH website before citing one in a submission.
| Guideline | Subject | Used in |
|---|---|---|
| ICH Q5A | Viral safety evaluation of biotechnology products derived from cell lines of human or animal origin | Ch. 6 (viral clearance), 3.2.A.2 |
| ICH Q5B | Analysis of the expression construct in cells used for production | Ch. 1, 3.2.S.2.3 |
| ICH Q5C | Stability testing of biotechnological/biological products | Ch. 5, 3.2.S.7 and 3.2.P.8 |
| ICH Q5D | Derivation and characterisation of cell substrates | Ch. 1, 3.2.S.2.3 |
| ICH Q5E | Comparability of products subject to changes in their manufacturing process | Ch. 6 |
| ICH Q6B | Specifications: test procedures and acceptance criteria for biotechnological/biological products | Ch. 2, 3.2.S.4 and 3.2.P.5 |
| ICH Q8, Q9, Q10, Q11 | Pharmaceutical development; quality risk management; pharmaceutical quality system; development and manufacture of drug substances | Ch. 2 (QbD), 3.2.S.2.6 and 3.2.P.2 |
| ICH S6(R1) | Preclinical safety evaluation of biotechnology-derived pharmaceuticals | Module 4 |
| ICH M4 (M4Q) | The Common Technical Document; its quality part | This chapter |
| FDA guidance (2015) | Quality considerations in demonstrating biosimilarity of a therapeutic protein product to a reference product | Ch. 6 |
| EMA guideline (2014) | Similar biological medicinal products (overarching guideline) | Ch. 6 |
One reference in specification §10.3 needs a correction before anyone copies it: USP general chapter <1220> is titled "Analytical Procedure Life Cycle". It is a general chapter about managing analytical procedures across their life cycle and is not specific to monoclonal antibodies, as the specification's label suggests. The ICH counterparts, Q2(R2) on validation and Q14 on analytical procedure development, are discussed in Chapter 8.
Every number that ends up in Module 3 is a record, and regulators expect records to be trustworthy regardless of whether they were written on paper or produced by software. The shorthand for that expectation is ALCOA+: data should be Attributable (who created or changed it), Legible, Contemporaneous (recorded when the activity happened), Original (or a certified true copy), and Accurate, plus Complete, Consistent, Enduring and Available. In the United States, 21 CFR Part 11 sets the conditions under which electronic records and electronic signatures are considered equivalent to paper records and handwritten signatures; in the EU, Annex 11 of the GMP guide covers computerised systems. Industry guidance such as ISPE's GAMP 5 describes a risk-based approach to validating such systems.
It is important to be explicit here, because the name "standard SDK" can suggest more than it delivers. The functions in BiopharmaSDK are pure calculations. They take numbers and return numbers. They have no notion of a user, a timestamp, an instrument, a sample, a lot or a reason for change; they write nothing to disk; they sign nothing. The types in types.ts have no identifier fields at all, so two QualityAttributes objects for different lots are indistinguishable. None of this is a flaw in a calculation library, but it means that a laboratory system built on the SDK carries the entire burden of Part 11 or Annex 11 compliance itself. A vendor that says "we use the WIA-BIO-016 SDK" has said nothing about the integrity of its records.
The practical pattern is to wrap every SDK call in a calculation record that stores the inputs exactly as supplied, the identity of the code that ran, the outputs exactly as returned, and the audit metadata. The envelope below is an illustrative design, not part of WIA-BIO-016.
{
"recordId": "calc-000731",
"function": "BiopharmaSDK.calculateBindingAffinity",
"sdkVersion": "1.0.0",
"codeDigest": "sha256:<digest of the built package>",
"inputs": {
"antibodyConc": 1e-9,
"antigenConc": 1e-8,
"complexConc": 9e-10,
"unit": "M"
},
"outputs": {
"kd": 1.011111111111112e-9,
"fractionBound": 0.8999999999999999,
"bindingStrength": "moderate",
"therapeuticSuitability": true
},
"sourceData": ["spr-run-2291/sensorgram.csv"],
"performedBy": "analyst-17",
"performedAt": "2026-01-01T09:30:00Z",
"reason": "initial calculation",
"signature": null
}Three details in that record come straight from running the code rather than from theory. The fractionBound for the specification's own Appendix A.1 input is not 0.9 but 0.8999999999999999, an ordinary floating-point effect; records must store the raw value and comparisons must use a tolerance. Second, if the complex concentration is zero, calculateBindingAffinity returns kd: Infinity instead of throwing, and JSON.stringify silently turns Infinity into null. A system that serialises results as JSON therefore loses the difference between "no binding observed" and "missing value" unless it handles non-finite numbers explicitly. Third, the codeDigest is what makes a record reproducible: without it, a later patch to the SDK could change a stored result's meaning without anyone noticing.
Where the obligations fall. Audit trail, access control, electronic signature, record retention, backup, and system validation belong to the system that stores and uses the results: the LIMS, the electronic notebook, the analytics platform. The SDK can make that system's job easier by being deterministic and versioned; it cannot do the job.
The specification's Appendix A gives three worked examples. They make natural golden vectors because they are part of the normative document, but they must be recomputed rather than copied, because one of the interpretations in the appendix is wrong. The table below was produced by running the version 1.0 SDK on those inputs.
| Vector | Input | Expected output (SDK 1.0) | Note |
|---|---|---|---|
| A.1 affinity | Ab 1 nM, Ag 10 nM, complex 0.9 nM | kd ≈ 1.0111 × 10⁻⁹ M; fractionBound ≈ 0.9; bindingStrength moderate; therapeuticSuitability true | Appendix says "high affinity"; both §4.1.2 and the code classify 1–10 nM as moderate |
| A.2 PK | Dose 100 mg, F 1.0, CL 0.2 L/h, Vd 5 L | auc 500 mg·h/L; ke 0.04 h⁻¹; halfLife 17.325 h; c0 20 mg/L; dosingInterval 24 h | Hypothetical small protein; not typical of an IgG |
| A.3 IRS | ADA 0.15, severity 5, duration 2, tolerance 0.5 | riskScore 3; riskLevel low; predictedADA 0.1545; monitoringFrequency standard | WIA triage heuristic, not a regulatory metric |
| Kinetics | kon 1 × 10⁵ M⁻¹s⁻¹, koff 1 × 10⁻⁴ s⁻¹ | kd 1 × 10⁻⁹ M; complexHalfLife ≈ 6931 s | Derived vector, not in Appendix A |
| PD at EC50 | C = EC50 = 1, Emax 100, n = 1 | effect 50; receptorOccupancy 0.5; therapeuticRange 0.5–9 | Occupancy uses EC50, not Kd (Ch. 4 defect) |
A golden vector fixes the behaviour of the code, including its defects. The PD vector above passes precisely because the SDK computes occupancy from EC50. When the defect is fixed, that vector must change, and the change must be recorded as a behavioural change in the release notes. This is the reason to keep vectors under version control next to the code rather than in a separate document.
Every input check in the SDK throws a BiopharmaError with code BIO007 (INVALID_PARAMETERS). Although BiopharmaErrorCode defines ten codes, BIO001 to BIO010, the other nine are never thrown by any function in version 1.0, so a test suite cannot expect them. The following inputs were confirmed to throw BIO007:
calculateBindingAffinity with a non-positive antibody or antigen concentration, or with a complex concentration larger than either reactant;calculatePharmacokinetics with non-positive dose, clearance or volume, or bioavailability outside 0–1;assessImmunogenicity with ADA rate outside 0–1 or severity outside 1–10;calculateKinetics with a non-positive rate constant;calculatePharmacodynamics with negative concentration or Emax, or non-positive EC50.Just as instructive are the inputs that should fail and do not. A zero complex concentration returns kd: Infinity with bindingStrength: "very-low". A toleranceFactor of zero in assessImmunogenicity produces an infinite risk score; a negative tolerance or duration factor produces a negative score, which the code classifies as low. Neither factor is validated. A conformance test suite should contain these cases as documented known behaviour, and an implementation that adds validation for them should declare that as a deliberate deviation.
The package manifest configures jest with the ts-jest preset and a test pattern of **/__tests__/**/*.ts or *.test.ts, and defines test, test:coverage and typecheck scripts. The source tree contains no test files, however, so the scripts currently have nothing to run. A minimal starting file could look like this:
// src/__tests__/golden.test.ts
import { BiopharmaSDK, BiopharmaErrorCode } from '../index';
const sdk = new BiopharmaSDK();
describe('Appendix A golden vectors', () => {
test('A.1 binding affinity is moderate, not high', () => {
const r = sdk.calculateBindingAffinity({
antibodyConc: 1e-9, antigenConc: 10e-9, complexConc: 0.9e-9,
} as any);
expect(r.kd).toBeCloseTo(1.0111e-9, 13);
expect(r.fractionBound).toBeCloseTo(0.9, 12);
expect(r.bindingStrength).toBe('moderate');
});
test('A.2 pharmacokinetics', () => {
const r = sdk.calculatePharmacokinetics({
dose: 100, bioavailability: 1, clearance: 0.2, volumeOfDistribution: 5,
} as any);
expect(r.auc).toBeCloseTo(500, 9);
expect(r.halfLife).toBeCloseTo(17.325, 9);
expect(r.dosingInterval).toBe(24);
});
});
describe('negative vectors', () => {
test('complex larger than antibody throws BIO007', () => {
let err: any;
try {
sdk.calculateBindingAffinity({
antibodyConc: 1e-9, antigenConc: 10e-9, complexConc: 2e-9,
} as any);
} catch (e) {
err = e;
}
expect(err?.code).toBe(BiopharmaErrorCode.INVALID_PARAMETERS); // 'BIO007'
});
});The as any casts are there because the input interfaces declare fields, such as units and method, that these examples leave out; a real test should construct complete objects.
Before any test runs, the code must compile. Running the TypeScript compiler (version 5.9) in strict no-emit mode over the version 1.0 sources reports 44 errors, and every one of them is a duplicate export: types.ts exports each type at its declaration and then again in a closing export type { … } block, re-exports BIOPHARMA_CONSTANTS, BiopharmaErrorCode and BiopharmaError a second time, and index.ts ends with export { BiopharmaSDK } after already declaring export class BiopharmaSDK. The errors are TS2323 ("Cannot redeclare exported variable") and TS2484 ("Export declaration conflicts with exported declaration"). The fix is purely mechanical: delete the two trailing export blocks in types.ts and the redundant line in index.ts. With that done, the functions run and produce the vectors in the table above. Until it is done, the typecheck and build scripts cannot be expected to succeed, and anyone who claims to have run the "WIA test suite" against the unmodified sources should be asked how.
The shell tool cli/wia-bio-016.sh does its arithmetic by piping expressions to bc -l. GNU bc does not accept scientific notation: the input 1e-9 is a syntax error. The defaults of calc-affinity and validate are written in exactly that notation, as are the classification thresholds inside the script (1e-12, 100e-12, MIN_THERAPEUTIC_KD=10e-9), and the help text's own examples use it. The consequences are worse than a crash, because the script does not crash:
$ bash cli/wia-bio-016.sh calc-affinity 2>&1 | grep -E 'error|Kd|strength'
(standard_in) 1: syntax error
...
Dissociation constant (Kd): 0.00e+00 M
Binding strength: LOW
$ bash cli/wia-bio-016.sh validate --affinity 1e-6 2>/dev/null | grep -E 'Affinity|VALID'
Affinity: Within therapeutic range
Candidate is VALID for development
$ echo $?
0Each failed bc call yields an empty string; an empty arithmetic test in (( )) evaluates as false; set -e does not stop the script because the failure happens inside a command substitution. The affinity command therefore prints a Kd of zero and calls it "LOW", and the validation command accepts a 1 µM binder, a thousand times weaker than the script's own 10 nM threshold, as "within therapeutic range". Passing the inputs in decimal form (0.000000001) fixes the displayed Kd but not the comparisons, because the thresholds are still in scientific notation. The calc-pk, immunogenicity and simulate-pkpd commands use plain decimals and behave correctly.
The robust fix is to leave bc out of anything that may see an exponent. awk parses scientific notation natively, both in expressions and in variables passed with -v:
calc() { awk "BEGIN { printf \"%.6e\", $1 }"; }
lt() { awk -v a="$1" -v b="$2" 'BEGIN { exit !(a + 0 < b + 0) }'; }
kd=$(calc "($ab - $cx) * ($ag - $cx) / $cx") # 1.011111e-09 for the defaults
if lt "$kd" 1e-12; then echo "ultra-high"
elif lt "$kd" 100e-12; then echo "very-high"
elif lt "$kd" 1e-9; then echo "high"
elif lt "$kd" 10e-9; then echo "moderate"
else echo "low"
fiAn alternative is to normalise each input once with printf '%.20f' before handing it to bc, but that silently discards every digit beyond the twentieth decimal place: precision shrinks as values get smaller (a femtomolar value keeps only six significant digits), anything below 10−20 becomes zero, and the thresholds inside the script still have to be rewritten as decimals as well. Whichever fix is chosen, the CLI's test cases should include the help-text examples verbatim, and the test harness should treat any output on standard error as a failure, since the exit code alone cannot be trusted.
WIA-BIO-016's own specification does not define conformance requirements. The four files spec/PHASE-1 to PHASE-4 contain annexes about test vectors, evidence packages, versioning and interoperability profiles, but these annexes are a shared WIA template: they appear essentially verbatim across the four files, and the files' headers carry a different standard identifier and date. The ideas they describe are sound and useful, and this section uses them, but they should be cited as the non-normative annex shared across WIA standards, not as requirements specific to WIA-BIO-016.
supported, partial (with a reason) or excluded (with a justification), so that a partial implementation is not mistaken for a full one.Three adjustments are needed before these elements fit this standard. First, WIA-BIO-016 has no numbered requirements, so the manifest has nothing to reference; an implementer has to define identifiers, and the least arbitrary choice is to anchor them to specification sections and SDK functions. Second, WIA-BIO-016 defines no network API, so an OpenAPI document does not apply; that item should be marked excluded with a reason rather than filled with an invented interface. Third, the annex refers to a vector directory (tests/phase-vectors/…) that does not exist in the source tree; the vectors in this chapter are a proposal, not a published WIA set.
{
"standard": "WIA-BIO-016",
"specVersion": "1.0.0",
"implementation": "example-lims-biopharma-module",
"implementationVersion": "2.3.1",
"requirements": [
{ "id": "BIO016-S4.1-KD", "status": "supported",
"evidence": "vectors/a1-affinity.json" },
{ "id": "BIO016-S5.2-RO", "status": "partial",
"reason": "receptor occupancy computed with Kd instead of EC50 (deliberate deviation from SDK 1.0)" },
{ "id": "BIO016-S6.2-IRS", "status": "supported",
"evidence": "vectors/a3-irs.json",
"note": "triage heuristic only; not presented to users as a clinical risk" },
{ "id": "BIO016-CLI", "status": "excluded",
"reason": "shell CLI not shipped" },
{ "id": "WIA-ANNEX-OPENAPI", "status": "excluded",
"reason": "WIA-BIO-016 defines no network API" }
]
}The requirement identifiers in this example are invented for illustration. The point is the shape: each line names a verifiable behaviour, states its status, and either points to evidence or explains the gap. A manifest in which every line says supported and none carries evidence is not a manifest; it is marketing.
Several of the corrections proposed in this book change observable behaviour: computing receptor occupancy from Kd, rejecting a non-positive tolerance factor, fixing the CLI comparisons. Under SemVer each of these is a change to what callers see, and whether it is major or minor depends on whether existing callers can rely on the old output. Fixing the duplicate exports, by contrast, changes nothing a caller can observe once the package compiles, and is a patch. An evidence package should state which SDK version, and ideally which package digest, its vectors were run against, so that an auditor can tell whether a passing matrix still applies after an upgrade.
The final boundary is the one most often crossed in practice. A WIA conformance claim is a statement about software: that a given implementation, at a given version, produces the specified outputs for a declared set of inputs, and declares honestly where it deviates. It is not a statement about a medicine, a manufacturing site or a clinical outcome.
| A conformance claim can say | A conformance claim cannot say |
|---|---|
| Version 2.3.1 of this module reproduces the WIA-BIO-016 golden vectors listed in its manifest | The product analysed with this module is safe, effective or approvable |
| These requirements are supported, these are partial for the stated reasons, these are excluded | The module is "fully compliant" with a standard that defines no numbered requirements |
| The evidence package was generated from this build and signed by this key | The system is validated under 21 CFR Part 11 or EU Annex 11 |
| The immunogenicity risk score is computed as defined by WIA | The score predicts clinical immunogenicity or is accepted by any regulator |
| The biosimilarity function applies the WIA per-attribute heuristic | The product is biosimilar or interchangeable under FDA or EMA criteria |
| — | The manufacturer holds GMP certification, or the product has regulatory approval |
Two reasons make this boundary more than a formality. The first is that several WIA-BIO-016 outputs look like regulatory conclusions: a function named assessBiosimilarity returns a field that can read "similar", and validateDrugCandidate returns timelines, costs and success probabilities. These are hard-coded heuristics, as Chapter 6 showed, and presenting them next to a certificate invites a reader to treat them as validated. The second is that the users of these tools work in a regulated industry where a misleading claim on a label or a sales document has consequences for the people who relied on it. A vendor that claims less than it could is inconvenienced; a vendor that claims more than it can support has misled its customers.
Chapter summary. The CTD, and above all its Module 3, is where the evidence built with WIA-BIO-016 is eventually read. The model covers characterization, quality attributes, stability and comparability reasonably well, and leaves specifications, reference standards, container closure and viral safety to the implementer. The SDK is a set of pure calculations with no data integrity features, so Part 11 and Annex 11 obligations rest on the surrounding system. Testing the version 1.0 sources exposes a package that does not type-check until duplicate exports are removed, only one error code in actual use, unvalidated edge cases, and a CLI whose scientific-notation inputs silently produce wrong answers with a zero exit code. Conformance evidence should follow the shared WIA template, adapted honestly, and a certificate should claim only what the evidence shows.
assessBiosimilarity, predictShelfLife and calculatePharmacokinetics, and why is the last one not in Module 3?RegulatoryPathway need to be split into agency, legal route and expedited programme for a portfolio-tracking tool?validate --affinity 1e-6 return a valid candidate with exit code 0, and why does passing 0.000001 not fix it?