Skip to main content

Modeling Viral Safety: Inactivation and Filtration as Risk-Reducing Steps

📍 Where we are: Part IV · Downstream, modeled — Chapter 14. The product is captured and concentrated. This chapter models the steps that exist not to improve the product but to reduce a risk — and forces the model to represent something genuinely awkward: the absence of a thing you hope was never there.

Every step so far has had a positive job: grow cells, separate product, capture antibody. Viral safety steps are different. Their purpose is to ensure that if an adventitious virus ever contaminated the process, it is inactivated and removed to a vanishingly small level. The standard approach uses orthogonal barriers — a low-pH hold that inactivates enveloped viruses, and a nanofiltration step that physically removes virus particles by size [1]. Modeling them stretches the ontology in a new direction, because the quantity that matters is not a property of the product but a measure of risk reduction — and because that measure is, for the most part, a validated claim rather than a per-batch measurement.

The simple version

Most kitchen steps make the dish better; some exist only for safety, like cooking chicken to a temperature that kills bacteria you hope were never there. You cannot easily prove "zero bacteria" in tonight's dinner — instead you validated, once and rigorously, that this cooking step reliably kills them, and then you simply confirm you hit the temperature each night. Viral safety works the same way: the killing power was proven in validation studies, and each batch confirms the conditions were met. This chapter models that distinction — between a capability proven once and a condition checked every time — which turns out to matter a great deal.

What this chapter covers​

We model viral inactivation and filtration as risk-reducing unit operations whose key attribute is a log reduction value (LRV), model the orthogonality of complementary barriers, and dissect a viral-safety step. The chapter's weight is on its unsolved part: how a graph represents absence and risk reduction, and the crucial difference — for data integrity — between a validated clearance claim and a measured per-batch result.

The attribute is risk reduction, not product quality​

A low-pH hold and a nanofilter both transform the capture pool into a safer material, laying ordinary derivedFrom edges: in instances.ttl the viral-inactivated pool bp:VIpool-001 is derivedFrom bp:PApool-001, and the nanofiltered pool bp:VFpool-001 is derivedFrom bp:VIpool-001, inserting both barriers as real intermediates in the golden genealogy. But the attribute these steps are designed to deliver is unlike any quality attribute so far. It is the log reduction value (LRV) — the number of orders of magnitude by which the step would reduce a viral load if one were present [1]. An LRV of 4 means a thousand-fold-times-ten reduction. This is not a measured property of this batch's product, the way monomer purity is; it is a measure of the step's capacity to reduce a hypothetical contaminant. Modeling it correctly means attaching the LRV not to the product material as a quality but to the step as a validated capability, and relating the per-batch record to the conditions (pH, hold time, filter integrity) that the validation showed deliver that capability.

The running example does exactly this. Each step bears its validated LRV through bp:hasClearanceCapability, an individual bp:LogReductionValue (a bp:Capability, itself a bp:Disposition), while the per-batch measured conditions — the pH and hold time the validation depended on — are bp:Quality individuals inhering in the cleared material via bp:inheresIn, the same shape monomer content uses:

@prefix bp:  <https://example.org/bioproc#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# The validated capability of the step (LRV 4.5), established once in a study.
bp:VI-001 a bp:LowPHHold ; rdfs:label "low-pH-hold viral inactivation" ;
    bp:hasInput bp:PApool-001 ; bp:hasOutput bp:VIpool-001 ;
    bp:hasClearanceCapability bp:LRV-VI-001 ;
    bp:orthogonalTo bp:VF-001 ;
    bp:realizes bp:VClear-Study .
bp:LRV-VI-001 a bp:LogReductionValue ; rdfs:label "low-pH-hold LRV (validated)" ;
    bp:lrvValue "4.5"^^xsd:float ; bp:clearanceMechanism "enveloped-virus inactivation by low pH" ;
    bp:isRealizedIn bp:VI-001 ; bp:establishedBy bp:VClear-Study .
# Per-batch measured conditions: qualities inhering in the cleared material.
bp:VIcond-pH a bp:LowPHHoldPHQuality ; rdfs:label "low-pH-hold pH (this batch)" ;
    bp:inheresIn bp:VIpool-001 ; bp:holdPH "3.6"^^xsd:float .
bp:VIcond-time a bp:HoldTimeQuality ; rdfs:label "low-pH-hold time (this batch)" ;
    bp:inheresIn bp:VIpool-001 ; bp:holdTimeMin "60.0"^^xsd:float .

The bearer of the per-batch conditions is bp:VIpool-001 — the viral-inactivated pool, derivedFrom bp:PApool-001, sitting on the running example's golden genealogy (WCB-CHO-001 → SEED-001 → BATCH-2026-001 → CLAR-001 → PApool-001 → VIpool-001 → VFpool-001 → POLpool-001 → DS-001 → DP-001). The LRV (4.5) hangs off the step through bp:hasClearanceCapability; the pH (3.6) and hold time (60.0 min) hang off the material through bp:inheresIn — the two-sided shape that keeps a validated capability and a per-batch measurement from being confused. Every token above is copied verbatim from instances.ttl.

Orthogonality is itself modeled, not just discussed. Two barriers are orthogonal when they remove virus by different mechanisms — inactivation by pH, removal by size — so a virus surviving one is unlikely to survive the other; total clearance is the sum of their LRVs [1]. In the graph the symmetric relation bp:orthogonalTo links bp:VI-001 and bp:VF-001 (LRV 4.5 and 4.2), and the total claimed clearance is a derived individual, bp:TotalClearance-mAb-A (bp:lrvValue 8.7), so a reviewer can ask "is the cumulative clearance sufficient, and is it genuinely orthogonal?" as a query rather than a manual tally. That query is a real, loadable file — queries/orthogonal-clearance.rq walks bp:hasClearanceCapability to each step's LRV and mechanism:

PREFIX bp: <https://example.org/bioproc#>
SELECT ?step ?lrv ?mechanism WHERE {
  ?step bp:hasClearanceCapability ?cap .
  ?cap  bp:lrvValue ?lrv ;
        bp:clearanceMechanism ?mechanism .
} ORDER BY ?step

Against the published data validate.py returns [('VF-001', 4.2), ('VI-001', 4.5)] — total 8.7, matching bp:TotalClearance-mAb-A exactly.

Identity card dissecting a viral-safety step: an input row for the capture pool material; two orthogonal process rows — a low-pH-hold inactivation step (mechanism: pH) and a nanofiltration removal step (mechanism: size exclusion) — each a unit operation; an LRV row on each step marked as a validated capability, not a per-batch product measurement; a per-batch-conditions block (pH value, hold time, filter integrity-test result) holding what is actually measured each run; a total-clearance row summing the orthogonal LRVs as a derived, checkable fact; and a contrast banner separating validated claim (proven once, in studies) from measured result (confirmed every batch). A safety step, unpacked: orthogonal barriers each carry a validated LRV (a capability), while each batch records only the conditions that validation showed deliver it — the validated-claim-versus-measured-result distinction made explicit. Original diagram by the authors, created with AI assistance.

A spine of materials — capture pool PApool-001 to viral-inactivated pool VIpool-001 to viral-filtered pool VFpool-001 — with two orthogonal clearance steps between them. Under the low-pH-hold step VI-001 sits its validated capability LRV 4.5 in green and, under the pool, the measured per-batch condition pH 3.6 and hold 60 minutes in violet. Under the nanofiltration step VF-001 sits its validated capability LRV 4.2 in green and the measured filter integrity PASS on nanofilter NF-01 in violet. The two capabilities sum into TotalClearance 8.7, established by the validation study, and an orthogonalTo arc links the two steps. Two orthogonal barriers summing to a validated total clearance of 8.7 — and the chapter's core distinction drawn in color: a validated capability (green) belongs to the step and holds for every batch, while a measured condition (violet) belongs to this batch's pool. Original diagram by the authors, created with AI assistance.

The unsolved part: modeling absence, and validated versus measured​

This chapter's difficulty is conceptual, and it exposes a limit that runs deeper than viral safety. The graph is built to assert what is — this batch derivedFrom that pool, this result hasValue 98.611. Viral safety asks it to be confident about what is not there: no infectious virus. But absence is not directly observable — you cannot measure "zero virus" in a batch, only fail to detect it down to a limit. So the assurance is structured indirectly: validation studies prove the steps can clear far more virus than could plausibly be present, and each batch confirms the conditions those studies relied on. The graph models a chain of inference — validated capability plus met conditions implies acceptable risk — rather than a measurement of safety itself. Representing that honestly (capability, conditions, inference) instead of inventing a fictitious per-batch "virus = 0" result is the correct but easily-botched modeling choice.

What makes this safe to model is that bp:Quality is grounded in the BFO category for a specifically dependent continuant — a property that cannot float free of a bearer. The alignment file pins it there explicitly, and pins bp:inheresIn to the BFO relation that links a quality to the thing it depends on:

@prefix bp:   <https://example.org/bioproc#> .
@prefix obo:  <http://purl.obolibrary.org/obo/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

bp:Quality   rdfs:subClassOf  obo:BFO_0000019 .   # BFO 'quality' (specifically dependent continuant)
bp:inheresIn rdfs:subPropertyOf obo:BFO_0000197 . # BFO 'inheres in' (inverse of 'bearer of')

Because bp:inheresIn is a sub-property of BFO inheres in and its declared range is bp:Material, the vocabulary will only let a measured per-batch condition attach to a material bearer — never to a process. That is the model's built-in honesty about the per-batch conditions: the pH and hold time are forced onto the cleared material, where they belong. The validated LRV is kept on a separate edge entirely — bp:hasClearanceCapability, an LRV individual typed bp:LogReductionValue (a bp:Capability, a bp:Disposition) — so the graph can never quietly record an LRV as if it were a bp:inheresIn quality measured on this batch's product. The two attributes use two different relations precisely so they cannot be confused, which is the distinction this chapter argues must be preserved.

This is the chapter where BFO's branch for realizable entities earns its keep, so it is worth naming the real categories the alignment points at. BFO splits specifically-dependent continuants — properties that need a bearer — into two families: a quality (obo:BFO_0000019, where bp:Quality lands) is simply had and is fully present whenever its bearer is, like this batch's pH; a realizable entity (obo:BFO_0000017, where bp:RealizableEntity lands) is only latent until something triggers it. BFO further divides realizables into three: a role (obo:BFO_0000023) a thing bears contingently and can shed, a function (obo:BFO_0000034, where bp:Function lands — the nanofilter's clearance function) that is its designed purpose, and a disposition (obo:BFO_0000016, where bp:Disposition lands) it bears in virtue of its physical make-up. An LRV is precisely a disposition: the step's latent capacity to clear virus, realized only if virus is ever present. That is why bp:LogReductionValue sits under bp:Capability under bp:Disposition, and why a measured pH sits under bp:Quality instead — the BFO category tree, not a local convention, draws the line between "what this step can do" and "what this batch's material is like." align.ttl pins each of these to its real, OLS-verified BFO 2020 IRI, so a reasoner that loads BFO sees the LRV as a realizable and the pH as a quality without any extra assertion from us.

There is a deliberate subtlety here, flagged in the vocabulary itself. BFO-strictly, a disposition inheres in a material entity, not a process — yet bp:hasClearanceCapability is declared with rdfs:domain bp:ViralClearanceStep, so the step bears the LRV. The skos:definition on the property in bioproc.ttl calls this out: the step carries the capability "for teaching clarity," while the per-batch conditions are modeled BFO-correctly as qualities of the cleared material. A more orthodox model would inhere the clearance disposition in the equipment or material and merely realize it in the step; the running example trades that orthodoxy for legibility and documents the trade rather than hiding it. That honest annotation — not pretending the shortcut is BFO-pure — is itself part of the modeling discipline this chapter is about.

Underneath sits a distinction the whole series should heed: validated versus measured. An LRV is a validated claim — established once, in dedicated studies, about what the process can do. A pH reading is a measured result — captured every batch, about what the process did. Conflating them is a real data-integrity failure: a graph that records an LRV as if it were measured on this batch asserts something no instrument observed, and a graph that records only the pH without linking it to the clearance it underwrites loses the reason the pH matters. The capture chapter met the same gap in cleaning validation, and it recurs wherever assurance comes from a study rather than a sensor. Modeling the provenance of every claim — was this established by validation or measured this run? — is straightforward to state, frequently skipped, and exactly what separates a graph that can defend a release from one that merely looks complete. The honest standard here is that viral safety is modelable, but only if the model refuses to pretend a validated capability is a per-batch measurement.

Why it matters​

Viral safety is where a graph's intellectual honesty is tested, because it cannot lean on a measured number. Model the LRV as a validated capability of the step, the per-batch record as the conditions that earn it, and the total clearance as a derived orthogonal sum, and the graph supports a defensible safety argument that a reviewer can interrogate. Fudge it — invent a per-batch clearance, or detach the conditions from the capability — and the graph quietly misrepresents the single most safety-critical claim in the whole process. More broadly, this chapter teaches the model to distinguish what was proven once from what is checked each time, a distinction that underwrites trust everywhere assurance is validated rather than observed.

In the real world​

Orthogonal viral clearance — low-pH inactivation plus nanofiltration, with LRVs established in validation studies and conditions confirmed per batch — is the regulatory expectation for monoclonal-antibody processes, codified in the viral-safety guidance and standard in commercial purification [1][2][3]. Plants already keep validation reports and per-batch condition records separately; the modeling advance is to link them — the batch's pH and hold time to the clearance study that makes them meaningful — so the safety argument is a connected, queryable structure rather than two unrelated filing cabinets. The validated-versus-measured discipline this step forces is exactly what the validation and governance chapters of Part VI generalize into how a regulated model is maintained at all.

Key terms​

  • Viral safety — the steps ensuring any adventitious virus is inactivated and removed to a negligible level; risk-reducing rather than product-improving.
  • Log reduction value (LRV) — the orders-of-magnitude reduction a step would achieve against a viral load if present; modeled as a validated capability of the step, not a per-batch product quality.
  • Orthogonal barriers — complementary steps that clear virus by different mechanisms (inactivation by pH, removal by size), so their LRVs sum into total clearance.
  • Validated claim versus measured result — an LRV is proven once in studies (capability); a pH or hold time is measured every batch (condition); conflating them is a data-integrity failure.
  • Modeling absence — representing assurance that a contaminant is not present as a chain of inference (validated capability plus met conditions implies acceptable risk), not as a fictitious per-batch "zero" measurement.
  • Low-pH hold — inactivation of enveloped viruses by holding the pool at low pH; in the running example a validated LRV of 4.5, with the per-batch pH (3.6) and hold time (60 min) recorded as measured conditions of the cleared material.
  • Nanofiltration — size-exclusion removal of virus particles by a virus-retentive filter (NF-01); a validated LRV of 4.2 that is orthogonal to the low-pH hold, so the two clear by different mechanisms and their LRVs sum.

Where this leads​

The product is now safe as well as captured. The next chapter, Modeling Polishing: Multi-Step Purification and Quality Attributes, models the final purification steps that drive impurities and product variants down to specification — and uses them to ask how a quality attribute like monomer purity is shaped not by one step but by the cumulative effect of a whole chain, and how the graph attributes a result to a process that no single node owns.