Last week, I kicked off a series of posts about conceptual models for digital twins of biotech labs by discussing the importance of getting the data model right. This week, I want to introduce a second, often overlooked, type of model - what I call the decision model.
Roughly speaking, everything in the data model is either a decision (determined by a person) or an observation (determined by some external phenomenon, whether it’s captured by a person or an instrument). So you might expect the decision model to just be the portion of the data model that captures decisions. But there’s an important layer on top of the data model, which I’m calling the decision model, that captures how this information is organized into discrete decisions.
For example, let’s look at plate maps. In some labs, every experiment uses a completely bespoke set of plates, custom tailored to the experiment or based on the whims of the bench scientist. In other labs, every experiment uses one of a small number of standardized plate templates, with a small list of factors that can be changed. Most labs have some mixture of the two.
Wherever your lab falls on this spectrum, the information that the data model captures about plate maps is the same - you need to know what was done to each well in each plate. But that information will be more useful in some forms than others. If a plate was based on a standard template, you could probably reverse engineer the template from what ended up in the wells, but it would be much easier to have the system directly track the template name. So the decision model determines the ideal structure of the data model.
On the other end of things, the decision model also shapes how users should be able to interact with the data. If you give users a completely open-ended plate map editor, but the lab uses standard templates, then it’s up to users to enforce the templates. So you can’t track what template they used, and it’s much more likely they’ll make a mistake. It would be much better for the system to let users select the template, then only edit the specified factors. In other words, the decision model determines how users should interact with the system.
So ultimately, the decision model is captured by the structure of the data model, and by elements of the workflow model that I’ll capture next time. But because it spans the two, and fundamentally defines how users interact with them, it’s worth calling out on its own, and thinking carefully about.
Scaling Biotech is brought to you by Merelogic. We design data models and infrastructure that help early-stage biotech startups turn their AI/ML prototypes into tangible impact. To learn more, send me an email at jesse@merelogic.net
Another great post! When I was running lab ops at the Center for Epigenetic Research at MSKCC, in many ways we first built the "right" data + decision model to reach our goals, before really ramping up our physical lab operations. It's a bit of an iterative process of course. Having the right tools and framework in place allowed us to not only scale rapidly but, more importantly, easily collaborate across institutions on a wide variety of projects (from discovery to clinical trials) and create meaningful scientific work. As scientists I think we too often get wrapped up on setting up the right experiments and executing them, treating data almost as an afterthought. This often winds us up in a bit of a vicious cycle.
At Ganymede, we've decided to argue for a different approach similar to what you're arguing here for digital twins. We touched on our vision for building a digital twin first, and then building the physical lab operations around them.
https://blog.ganymede.bio/biotech-and-biopharma-needs-to-start-thinking-about-physical-twins-not-digital/