Based on discussions with those in the community we came up with several different ways of categorizing laboratory autonomy (see below). This is key because it may help us identify which infrastructure we can develop that will have cross-domain applicability.
Some ways to categorize laboratory autonomy:
- By domain – huge diversity and hierarchical structure
- By experimental modality – equipment/task specific
- By type of problem – different types of closed loops, may even cross domains
Are there other ways we are missing? What are the pros and cons of each categorization?
1 Like
Scale, connectedness, and timelines come to mind as well. For example, the tools that are most useful in an isolated lab getting started with a few modules may be different from the tools that are most useful in a multi-lab, many-module system. This is where timelines (i.e., some forecast of the development process in terms of lab goals) come into play - some may be starting out small but are likely to scale rapidly. Others may be less likely. I suppose that gets more into technical debt concepts. In this case, perhaps the groupings would be:
- small, isolated systems (up to a few people, usually on a single desk)
- medium, single-lab systems (up to a couple PIs, usually within a single lab)
- large, interlab systems (up to a few distinct organizations, separate networks and financial accounts)
1 Like