---
title: "Harmonizing bioprocess metrics across instruments and runs"
slug: harmonizing-bioprocess-metrics-across-instruments-and-runs
date: 2026-08-26
author: "Invert Team"
category: product
summary: "Harmonizing bioprocess metrics across instruments and runs usually stalls behind a naming committee. Given a simulated library of 2,486 metric definitions, Invert Assist triaged 209 candidate matches against the parent metrics already in place, reconciled their unit strings against the unit registry, and staged 53 parent-child mappings across 6 parent metrics for review, with nothing applied to the database. The argument: standardization should not be a gate to doing science, and \"we'll fix it later\" works when changes are staged, reviewed, and logged."
url: https://invertbio.com/blog/harmonizing-bioprocess-metrics-across-instruments-and-runs
---
# Harmonizing bioprocess metrics across instruments and runs
**Invert Team** · August 26, 2026 · Product
_Harmonizing bioprocess metrics across instruments and runs usually stalls behind a naming committee. Given a simulated library of 2,486 metric definitions, Invert Assist triaged 209 candidate matches against the parent metrics already in place, reconciled their unit strings against the unit registry, and staged 53 parent-child mappings across 6 parent metrics for review, with nothing applied to the database. The argument: standardization should not be a gate to doing science, and "we'll fix it later" works when changes are staged, reviewed, and logged._
Somewhere in almost every bioprocess organization, there is a spreadsheet, a working group, or a very long meeting devoted to deciding what things should be called.
Invert Assist · working through the question, live
Assist reads the full metric library, matches 209 unattached metrics against the parent metrics already in place, reconciles their unit strings, and stages 53 parent-child mappings across 6 parents for review. Nothing is applied to the database. Illustrative example, simulated data.
Is it *Agitation* or *Impeller Speed*? Is this property *yield* or *recovery*? Which vocabulary should every site use? These are good questions. The mistake is thinking you have to answer all of them before the data can be useful. Because you usually discover what is wrong with a data model only after you start asking the data questions.
Take impeller speed. One bioreactor records *Agitation (rpm)*. Another calls it *Stirrer Speed (1/min)*. An older system exports *AGIT_PV*. Looking at one run, there is no real problem. A scientist understands what each means.
Then someone asks: how did impeller speed relate to performance across five years of runs? Now the names matter. A query finds *Agitation* but misses *Stirrer Speed*. Someone remembers those two but forgets *AGIT_PV*. Before answering the scientific question, you have to solve a naming problem you did not know you had.
That is how a lot of standardization actually happens: you ask a real question, something breaks, and the break tells you what needs to be fixed.
## Standardization should not be a gate to doing science
This is why perfecting the data model before loading historical data can be backward. Some inconsistencies only become visible when datasets meet. One team put strain in the run name; another stored it as a metadata tag. Two sites use different words for the same process step. Two instruments report the same quantity in different units.
And even if you settled every naming question today, the vocabulary would move again. New equipment arrives. Sites merge. Assays change. The useful data model is not the one that never changes. It is the one that can change without losing the record.
We gave Assist this problem in a simulated database containing 2,486 bioprocess metric definitions. The instruction was simple: find metrics that represent the same underlying measurement and stage the proposed harmonization for review. That requires more than matching names.
*Agitation (rpm)* and *Agitation Power (W)* look related, but they measure different things. Meanwhile, *Agitation (rpm)*, *Stirrer Speed (1/min)*, and *AGIT_PV* look different but all represent impeller speed. Assist proposed grouping genuine matches under Invert Parent Metrics.
The original names do not disappear. The instrument can still call its signal *Stirrer Speed*. But a scientist can ask for impeller speed and retrieve the runs where another system called it *Agitation*.
The same applies to units. *Base Addition Rate (mL/min)* and *Base Pump Rate (L/h)* describe the same quantity in different units. Once that relationship is captured, the conversion becomes something the system handles rather than something every analyst has to redo.
In the simulated catalog, Assist triaged 209 candidate matches against the parent metrics already in place, reconciled their unit strings against the unit registry, and staged 53 parent-child mappings across 6 parent metrics for review. Nothing was silently rewritten.
Figure 1. From the full metric library to staged, review-ready parent-child mappings
## “We’ll fix it later” can actually work
There is a reason people distrust that phrase. Usually, “later” means a spreadsheet: rename a column, save another copy, and eventually lose track of which version is authoritative. That is not adaptability. It is loss of control.
With Assist, proposed changes are staged for review. A person approves them. Approved changes are attributed and logged, while the original source data remains intact. So you can improve the structure without erasing the history.
And the improvement can apply backward. If you decide today that *Agitation*, *Stirrer Speed*, and *AGIT_PV* should all resolve to impeller speed, that mapping can make years of already-loaded runs easier to query too.
Figure 2. New child metrics attached to each parent · existing children preserved
The data has not changed. Your understanding of it has.
## The library should get better as you use it
This is also a practical way to think about FAIR. Interoperability is difficult to design entirely in advance because you discover it by trying to make datasets work together. Do these two sites mean the same thing by *yield*? Does one instrument’s *Stirrer Speed* correspond to another’s *Agitation*? Can the same query work across both? You learn by using the data.
So the goal should not be to finish standardizing everything before bringing the history in. Bring the data in. Ask questions. Learn where the structure gets in the way. Then improve it in a way that remains reviewable and auditable.
A good run library is not valuable because every piece of data entered under the perfect name. It is valuable because what the organization learns can accumulate there. You cannot anticipate every question your scientists will ask three years from now. You should not have to.