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.
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.
“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.
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.
Metric counts and examples are from a simulated bioprocess database and are shown as one illustrative example.
