VAILabs: Modular Virtual Lab Workflows

• VAILabs is an open-source, modular workbench that implements the Virtual Laboratory concept by integrating simulation, modeling, and real-world experiments.
• It unifies fragmented digital tools across research workflows by supporting interactive loops, human intervention, and hybrid digital-physical operations.
• Its XML-based, modular design enables rapid, reproducible iteration in applications such as materials design, robot co-adaptation, and drug discovery.

VAILabs is an open-source, modular, domain-agnostic workbench and toolbox for implementing the Virtual Laboratory concept in scientific research. In this usage, a Virtual Laboratory is not a VR simulator or an educational mock-up, but a digital environment for virtualization or emulation of operations carried out in a physical laboratory and, more broadly, a collection of computational tools and resources that support the entire scientific process while connecting to the physical world through suitable interfaces. VAILabs is presented as both a conceptual framework and a proof-of-concept software library for iterative scientific discovery, with explicit support for simulations, machine-learning models, optimization, instrument interfaces, human interaction, and hybrid digital-physical loops (Sevilla-Salcedo et al., 8 Jul 2025).

1. Concept and motivation

VAILabs was developed in response to a structural problem in contemporary research workflows: much of science still advances through iterative trial-and-error, but the digital tools that could accelerate that process remain fragmented across disciplines and workflow stages. The motivating observation is that researchers increasingly have access to simulations, machine-learning surrogate models or proxies, optimization methods such as Bayesian optimization, LLM-based assistants, and automated or semi-automated instruments, yet these resources are usually implemented as domain-specific point solutions rather than as a reusable framework for end-to-end scientific iteration (Sevilla-Salcedo et al., 8 Jul 2025).

The system is therefore positioned as a concrete implementation of the Virtual Laboratory idea for “domain-agnostic workflows for research.” Its target setting is neither a fully automated “robot scientist” pipeline nor a conventional static workflow manager. Instead, it addresses scientific processes that are dynamic, combine physical and digital steps, and require human intervention at intermediate checkpoints. The paper explicitly argues that standard workflow managers such as Snakemake, Nextflow, and Kedro handle pipelines well but do not naturally support interactive loops or human-in-the-loop checkpoints, while instrument platforms such as Labber focus on logging and hardware control rather than workflow logic, and LLM-agent frameworks remain largely language-centric rather than experimentally grounded (Sevilla-Salcedo et al., 8 Jul 2025).

A central implication is that VAILabs treats scientific discovery as a configurable iterative process rather than as a fixed production pipeline. The framework is intended to make recurrent research patterns—initialization, preprocessing, modeling, decision-making, environment interaction, user feedback, and output logging—available as reusable software abstractions. This suggests a shift from isolated laboratory scripts toward a generalized orchestration layer for hybrid computational and experimental research.

2. Architectural organization

The core software architecture is organized around three nested concepts: Modules, Plugins, and Cores. A module is a generic container for a workflow role; a plugin is a concrete implementation of that role; and a core defines the required methods and attributes that compatible plugins must implement, while also managing plugin instantiation and execution. The paper’s example is the DataProcessing core, where a plugin such as Binarizer must implement methods like transform() and accept required inputs such as the dataset $X$, together with optional parameters such as whether to modify data in place (Sevilla-Salcedo et al., 8 Jul 2025).

The framework identifies two foundational modules—Initialiser and Output—and five further fundamental requirements: Data Processing, Decision Making, Environment, Modeling, and User Interaction. The Initialiser establishes the problem domain, contextualizes the task, determines whether the problem is supervised or unsupervised, detects the presence of data partitions, and prepares downstream modules with compatible plugins. The Output module determines what data to save and where to save it.

Module	Role	Representative content
Initialiser	Workflow entry point	problem context, supervised/unsupervised choice, data partitions
Data Processing	Preprocessing and transformations	scaling, feature selection, multivariate analysis
Modeling	Learning, inference, analysis	supervised learning, unsupervised learning, scoring-function inference
Decision Making	Propose next actions	Bayesian optimization
Environment	Execute simulated or physical processes	PyBullet, custom environments, devices, real-time measurements
User Interaction	Manual feedback and override	review suggestions, alter parameters, expert input
Output	Workflow exit point	save intermediate and final outputs

This architecture achieves domain-agnosticity by externalizing domain-specific logic. General computational tools and domain-specific models are not part of the core environment; they are accessed through general interfaces. As a result, a simulator, a molecule generator, an RL environment, an optimization library, or a physical instrument controller can all appear as plugins under stable module families rather than as bespoke code paths (Sevilla-Salcedo et al., 8 Jul 2025).

3. Workflow description, execution, and interaction model

The principal declarative artifact in VAILabs is an XML-based workflow description, described as the “cornerstone” of the proposal and as the “blueprint” for research experiments. The XML file specifies the process sequence, selected modules, data dependencies, execution logic, loops, function selections, and parameters. The framework then instantiates plugins, manages execution order, handles background processes, passes data between modules, and stores intermediate and final outputs (Sevilla-Salcedo et al., 8 Jul 2025).

The paper does not introduce a dedicated mathematical workflow calculus or a VAILabs-specific optimization objective. Instead, it describes workflows as sequences of module invocations with loops, nested loops, branches, pauses, and human-input points. This suggests a directed computational graph in which module-plugin instances behave as nodes and data dependencies behave as edges, but that graph interpretation is an inference rather than a formalism stated by the framework itself. Likewise, the iterative research pattern repeatedly instantiated in the case studies can be read as a loop of the form

$D_{t+1} = D_t \cup \{(x_t, y_t)\},$

where $x_t$ is a proposed experiment or candidate and $y_t$ is the resulting evaluation, but the paper presents this only as a reconstructed abstraction rather than as native VAILabs notation (Sevilla-Salcedo et al., 8 Jul 2025).

A distinctive feature is explicit support for real-time intervention during execution. The system can pause at any stage, display intermediate outputs, allow plugin reconfiguration mid-run, and resume without restarting the workflow. A GUI is described for visualization and control, showing pipeline stages and current status. If no user input is detected, the system automatically proceeds to the next stage. This makes User Interaction a first-class workflow component rather than an external convenience layer. The same design also supports local deployment, integration of new Python-based modules without workflow recompilation, and systematic internal handling of data passing, storage, and workflow state (Sevilla-Salcedo et al., 8 Jul 2025).

4. Proof-of-concept workflows across scientific domains

The paper’s main empirical contribution is not a benchmark suite but three proof-of-concept mappings from published research tasks into the VAILabs workflow vocabulary. These demonstrations are intended to show structural feasibility across heterogeneous domains rather than to prove superiority over alternative orchestration systems (Sevilla-Salcedo et al., 8 Jul 2025).

The materials-design case maps the perovskite-stability workflow of Sun et al. into VAILabs. The search space is

$Cs_xMA_yFA_{1-x-y}PbI_3, \qquad x,y \in [0,1],$

with degradation tests taking about 100 hours per evaluation. The original process combines synthesis, physical degradation testing, automated imaging, image analysis, and Bayesian optimization. The optimization target is an image-derived proxy called the instability index $I_c$. In the cited workflow, a stable composition region was identified while sampling only 1.8\% of the discretized composition space, corresponding to 112 samples and four degradation tests in total. In VAILabs terms, synthesis and testing appear as Environment operations, image analysis as Modeling or Data Processing, Bayesian optimization as Decision Making, and termination as User Interaction (Sevilla-Salcedo et al., 8 Jul 2025).

The robot co-adaptation case represents a bi-level optimization problem in which a robot’s morphology and behavioral policy are optimized jointly. The lower level learns behavior for a fixed morphology using reinforcement learning with interaction data stored in a replay buffer; the higher level optimizes morphology parameters using Bayesian optimization, evolutionary methods, or surrogate-based search. VAILabs maps this as nested loops: an inner Environment-centered RL loop and an outer Decision Making loop over morphology proposals, with optional expert inspection before committing to new designs. This example is important because it shows that VAILabs is not restricted to wet-lab experimentation; a fully digital, simulation-heavy workflow can also be represented within the same module vocabulary (Sevilla-Salcedo et al., 8 Jul 2025).

The de novo drug-design case maps Task 1 of Sundin et al. into a human-in-the-loop generative workflow. A molecule generator implemented with REINVENT proposes candidates; an active-learning strategy selects informative molecules; a chemist or synthetic chemist provides binary $0/1$ feedback; and a Modeling component infers scoring-function parameters from labeled molecules. The workflow is organized as an outer generation loop and an inner active-learning loop. This case is the clearest demonstration that VAILabs treats human feedback, generative modeling, and iterative model refinement as composable research operations rather than as separate software ecosystems (Sevilla-Salcedo et al., 8 Jul 2025).

5. Position within the broader virtual-laboratory landscape

VAILabs is part of a broader and terminologically crowded landscape of “virtual laboratory” systems, but its meaning is specific. It should not be conflated with educational virtual labs or with immersive laboratory simulators. The paper explicitly distinguishes its notion of a Virtual Laboratory from educational platforms such as PhET, ChemCollective, Labster, and Amrita Virtual Labs, which simulate experiments for teaching and do not target new scientific discovery or real-world laboratory integration (Sevilla-Salcedo et al., 8 Jul 2025).

It is also distinct from similarly named platforms in adjacent literatures. The Virtual Experiences Lab (VxLab) at RMIT University is described as “a research and research training infrastructure and capability platform for global collaboration,” with visualization facilities, networking, videoconferencing, high-performance computation, simulation, and robotic instruments; it does not mention VAILabs, and its formal name is VxLab, formerly VITELab (Peake et al., 2015). Likewise, V-Lab is a VR educational application development framework for science-laboratory training, developed as an extension of Onlabs within XR2Learn; it is also not named VAILabs (Zafeiropoulos et al., 2024).

Within research infrastructure, VAILabs is positioned between several existing categories. Unlike robot scientists and highly task-specific autonomous labs, it does not require full automation. Unlike Snakemake, Nextflow, and Kedro, it is explicitly designed for conditional repetition, interactive pauses, and hybrid digital-physical workflows. Unlike LLM-agent frameworks, it includes explicit abstractions for environment interaction, structured sequencing, reproducibility, and user intervention. A plausible implication is that VAILabs is best understood as a workflow-level integration framework rather than as a domain model, a simulator, or a robotics platform in its own right (Sevilla-Salcedo et al., 8 Jul 2025).

6. Limitations, open problems, and prospective development

The paper presents VAILabs as a usable proof-of-concept, not as a mature universal platform. Its strongest evidence is architectural: an open-source codebase, a modular implementation structure, XML workflow descriptions, GUI-based control, and three cross-domain workflow mappings. It does not provide formal benchmarks against competing workflow systems, quantitative usability studies, timing or throughput evaluations, extensive ablation studies, or a proof that arbitrary scientific processes can be captured by the current module set (Sevilla-Salcedo et al., 8 Jul 2025).

Several open problems are identified explicitly. One is the difficulty of mapping arbitrary scientific workflows into the proposed modular structure. Another is semantic compatibility across modules: two modules may connect syntactically while remaining scientifically mismatched at the level of meaning or assumptions. Additional unresolved issues include the need for shared standards and robust default plugins, more user-friendly workflow authoring beyond XML alone, broader community adoption, faithful integration with real-world instruments, infrastructure maintenance, financial cost, UX design, and scalability for many concurrent users (Sevilla-Salcedo et al., 8 Jul 2025).

The paper nonetheless proposes a clear development trajectory. Future directions include broader deployment across scientific domains, community-driven extension of modules and plugins, interface standardization, improved workflow authoring tools, richer User Interaction modalities, and the embedding of LLMs or reasoning engines into the structured workflow substrate. The conclusion also points toward richer feedback channels, including eye tracking or brain-computer interfaces, as possible extensions of the interaction model (Sevilla-Salcedo et al., 8 Jul 2025).

In that sense, VAILabs occupies a specific place in AI-for-science infrastructure. It is not primarily a new model family, an automated laboratory stack, or a teaching simulator. Its main contribution is to argue that many research activities become more reusable, more reproducible, and more interoperable when they are expressed as modular Virtual Laboratory workflows with explicit support for loops, nested loops, physical experiments, simulations, and human decision points. The framework’s significance therefore lies less in algorithmic novelty than in its attempt to provide a common executable substrate for scientific discovery across domains (Sevilla-Salcedo et al., 8 Jul 2025).