Built Once, Used Many Times

Why Reuse Beats Reinvention on a Real Platform

A shared substrate doesn’t compound anything on its own. It compounds only when the workflows running on top of it get reused instead of rebuilt.

Blog 1 made the case that platforms compound because they have real anatomy underneath them – schema, taxonomy, workflow expertise, ontology, intelligence – instead of a stack of unrelated tools bolted together. Blog 2 showed what that anatomy looks like inside Solix EAI Pharma: one Semantic Content Library sitting under all eight discovery capabilities, carrying identity and memory between them so a finding in one shows up correctly in the next. Both posts leaned on an assumption we never actually tested: once a capability is built on that substrate – the SCL – does it stay built? This post pokes at that assumption, and along the way grounds the whole argument in something you can go look at right now – Virtual Screening.

A Good Substrate Can Still Get Wasted

Say the substrate really is as clean as Blog 2 described. Canonical IDs everywhere, no more TNF quietly meaning something different than TNFA depending on who typed it in. That solves the data side of the fragmentation problem. It doesn’t solve the workflow side. If every program still gets its own hand-rolled virtual screening model, its own docking script cobbled together for that one deadline, its own ADMET filter written from scratch by whoever got stuck with the job – the fragmentation didn’t go away. It just moved up a floor. The substrate’s unified. The work sitting on top of it isn’t.

Worth saying plainly: a platform must industrialize its workflows the same way it industrializes its data, or none of this holds together. Otherwise, every team keeps re-deriving the same fifty lines of logic, and none of that effort ever compounds. It just gets redone, quietly, forever.

The Same Mistake, One Floor Up

Patrick Grady’s root-cause essay in the Unvarnished series gets at this well. His argument isn’t that R&D is short on data, compute, or smart people – it’s a design failure, made worse by an odd economic habit: most of what a given R&D workflow actually does is common across the industry, yet gets treated like it’s bespoke to each team, each program, sometimes each individual scientist. Descriptor generation, model training, ranking logic – the mechanics repeat constantly. The habit of reusing them almost never does.

That habit costs more than duplicated hours. A model built for one program and then forgotten can’t pick up feedback from later runs. Nobody can audit it six months later when a question comes up about how a prediction was made. It can’t get sharper just because more people used it. Treat common work as bespoke often enough, and you cap how much any workflow is ever allowed to learn.

Projects vs. Products

The fix sounds simple even though it’s a slog to pull off: stop treating a workflow like a project and start treating it like a product. A product gets built once, checked against real data, versioned, and put somewhere governed. Next time a program needs the same capability, someone reuses it instead of rewriting it. And because every run gets logged, the thing keeps improving – program ten benefits from everything programs one through nine already proved, instead of starting cold. A project just ships once and gets forgotten the moment its deadline passes.

That’s not a small distinction. It’s the difference between an operation that gets faster the longer it runs a given workflow, and one that pays full setup cost every single time, forever.

Not a New Layer – Just the Old One, Finally Real

This isn’t a sixth item tacked onto Blog 1’s five-layer anatomy. It’s what makes the workflow-expertise layer real instead of aspirational. That layer was described as the structure of context – the encoded rules that tell a system what “good” looks like for a given task. If that structure only ever lives in one scientist’s personal script, tossed after a single program, it was never really a structure at all. It was tribal knowledge, sitting in one person’s head, good for exactly one use. Turning a workflow into a product is what converts that tribal knowledge into something the whole organization can draw on – the same way giving something a canonical ID is what turns taxonomy from a nice idea into a fact on the ground.

Virtual Screening Is the Proof

That’s the theory. It’s easier to see it hold up in something that already exists than to keep arguing it in the abstract, so here’s where it gets tested: Solix EAI Pharma’s Virtual Screening is built exactly this way – prebuilt, code-free, configurable, and reusable by design. Researchers create an experiment, define the data source and target, import and standardize compounds, preview them, generate and rank descriptors, profile and cleanse the data, train and deploy a model, and run predictions against new compounds.

That’s the workflow-expertise layer, built as an actual product instead of talked about as a good idea – prebuilt and governed rather than scripted once and abandoned. And because it draws on the same substrate from Blog 2, a target flagged in a disease gene signature, or a toxicity flag written back from ADMET, is available to a screening run the moment it exists. No translation step required to use it.

Two things about the product make the reuse argument concrete rather than aspirational: the Model Registry and Active Learning.

Once a model’s trained and validated, it doesn’t have to end as a one-time experiment – it can be registered in the Model Registry instead. That’s a governed place to keep trained models, their versions, and everything associated with them, so the next screening program can actually find them. Build it, register it, deploy it – and the next time a program needs the same capability, somebody reuses it instead of retraining one from scratch. That’s what turns a trained model from a one-off output into a computational asset the next several programs can draw on.

Reuse gets more valuable still when the model keeps learning from what happens in the lab. Once it predicts and ranks candidate compounds, a subset gets tested experimentally – and whatever comes back, whether it confirms the prediction or contradicts it, feeds into that same model through active learning. The model gets retrained on the new evidence and goes back to work on the next screening cycle: predict, test, learn, redeploy, predict again. A screening campaign stops being its own isolated event and starts being one more round of training data for the next one.

That’s the broader principle behind Solix EAI Pharma: the value of an AI workflow shouldn’t end when the first experiment does. The model, the workflow, even the data along the way – all of its meant to be a reusable asset for whatever comes next, not a one-time cost.

Where This Leaves the Series

Three posts, one argument, three angles on it. Blog 1: a platform needs real anatomy before intelligence can compound at all. Blog 2: the shared substrate that carries identity and memory across eight capabilities. This post: the substrate is necessary but not sufficient – the workflows running on it must be built once and reused, not rebuilt every time a new program shows up. Virtual Screening isn’t a side example tacked onto that argument. It’s what the argument looks like once someone builds and runs it.

Note & References

The Program A–F comparison above is an illustrative diagram constructed to demonstrate the reuse principle described in this post, not a documented customer case study.

• Grady, P. “On Platforms I: What They Are And Why They Matter.” Unvarnished (Substack).
• Grady, P. “On Platforms II: The Five-Layer Anatomy That Turns Chaos Into Coherence.” Unvarnished (Substack).
• Grady, P. “From First Principles: Root Cause Analysis and Non-Consensus Findings.” Unvarnished (Substack).
• Solix Technologies. “Solix EAI Pharma — Virtual Screening.” pharma.solix.com.
• Kummetha, J. “Virtual Screening with Active Learning” — concept and supporting graphics.

Product screens (Registered Models, Relaunch Trained Models, Experiments & Results History) are excerpted from the Solix EAI Pharma Virtual Screening product overview.

Acknowledgement: ‘Built Once, Used Many Times’ image elements in this post were generated using AI technology from Google.