NIMO: Open-Source Decision Engine for Labs
- NIMO is an open-source platform for autonomous materials discovery that integrates AI-based experiment planning with heterogeneous laboratory systems.
- It employs a candidate-pool architecture and CSV-based file mediation to decouple hardware-software integration and support twelve distinct optimization algorithms.
- NIMO enables closed-loop experimentation via a unified Python API and MCP-mediated orchestration through the NIMO Controller for seamless human and AI interaction.
NIMO is a term with multiple distinct meanings in the research literature. In recent work on self-driving laboratories, it most prominently denotes an open-source software platform and decision-making engine for closed-loop materials exploration, evolved from NIMS-OS and designed to connect diverse AI experiment-planning methods with heterogeneous robotic, legacy, or human-operated experimental systems (Tamura et al., 14 Jun 2026). In the closely related “NIMO Controller” architecture, NIMO is specifically the underlying decision-making engine/library, whereas the controller is the Model Context Protocol (MCP)-based orchestration layer that exposes NIMO and other laboratory functions through a common interface for both human users and AI agents (Yoshikawa et al., 13 May 2026). The same string also appears in unrelated contexts, including “NIMO: a Nonlinear Interpretable MOdel” in machine learning, the graphical programming language “NiMo,” and the catalyst designation NiMo/AlO, so domain-specific disambiguation is essential (Xu et al., 5 Jun 2025, Aráoz et al., 2015, Castello et al., 2019).
1. NIMO in autonomous materials discovery
In the materials-discovery literature, NIMO is a software platform for autonomous experimentation whose central purpose is to remove a practical bottleneck in self-driving laboratories: connecting many different optimization algorithms to many different kinds of laboratory hardware, each with its own control software, data format, and experimental constraints (Tamura et al., 14 Jun 2026). The platform is described as the evolution of NIMS-OS into a reusable orchestration and AI-planning system for closed-loop experimentation. Its design is motivated by two stated problems: AI/hardware integration is fragmented, and materials-discovery goals are diverse.
A recurrent source of confusion is the distinction between NIMO and NIMO Controller. In the MCP-based orchestrator paper, NIMO is the underlying decision-making engine/library used for experiment planning and optimization, originally developed as NIMS-OS and later named NIMO. NIMO Controller is the orchestration framework that wraps NIMO and other self-driving-laboratory components so they can be accessed uniformly by both human users and AI agents (Yoshikawa et al., 13 May 2026). This distinction matters architecturally: NIMO supplies experiment-selection and update logic, whereas NIMO Controller supplies protocol mediation, frontend generation, and workflow execution.
The recent SDL papers therefore use “NIMO” in two nested senses: a decision-making core and a broader experimental software platform. This suggests that, in autonomous-science usage, NIMO is best understood not as a single optimizer but as an interoperability layer for closed-loop experimentation.
2. Core architecture and operational principles
The NIMO platform is organized around three design paradigms: modular AI–robot decoupling via simple CSV file exchange, a discrete candidate-pool architecture, and a unified Python interface pre-loaded with twelve distinct AI algorithms (Tamura et al., 14 Jun 2026). The closed loop has three explicit stages: selection, evaluation, and update. NIMO reads a candidate-pool file, candidates.csv, writes selected experiments to proposals.csv, and then expects experimental results to be written back into the candidate-pool file.
This file-mediated design is presented as the key to language-agnostic and hardware-agnostic integration. Communication occurs exclusively through files rather than in-memory Python objects. As a result, NIMO can connect to Python, MATLAB, LabVIEW, Visual Basic, shell scripts, or vendor-specific code, and only one wrapper module is needed to connect a new instrument (Tamura et al., 14 Jun 2026). The same mechanism also makes NIMO interoperable with other orchestration frameworks.
The candidate-pool architecture is equally central. Instead of allowing an optimizer to propose arbitrary points in a continuous box, NIMO assumes that every physically feasible experimental condition has been pre-enumerated in a tabular CSV pool. Each row is one feasible condition; measured rows become training data, while blank rows remain selectable candidates. The proposal file includes an actions column containing zero-indexed row identifiers that map proposals back to the original pool. This design allows domain knowledge to be encoded directly in the search space by omitting invalid rows, sampling sensitive parameters more finely, or enforcing ordering and feasibility constraints without modifying the optimizer itself (Tamura et al., 14 Jun 2026).
The platform exposes this logic through a unified API. The representative call given in the paper is:
8
Because the candidate-pool format is shared across methods, the same hardware integration can be reused while swapping exploration algorithms.
3. Algorithmic repertoire and exploration regimes
NIMO’s algorithm portfolio is designed for heterogeneous experimental objectives rather than for a single canonical optimization problem (Tamura et al., 14 Jun 2026). The twelve algorithms are grouped by task type.
| Category | Algorithms | Role |
|---|---|---|
| Optimization | PHYSBO, BOMP, NTS, COMBI | Bayesian optimization, shared-batch constraints, threshold discovery, composition-spread exploration |
| Target-range and objective-free exploration | PTR, BLOX | Target-window search and broad coverage of property space |
| Categorical and ranking-based exploration | PDC, RSVM | Phase mapping and ordinal preference learning |
| Initial sampling | RE, DOE, ES | Random seeding, space-filling design, deterministic enumeration |
| LLM-based planning | LLMEP | Text-valued, qualitative, or structure-aware planning |
PHYSBO is the main Bayesian optimization engine. It uses Gaussian process regression to predict objective values and predictive variance, then selects experiments by maximizing an acquisition function. For single-objective problems it supports Thompson sampling, expected improvement, and probability of improvement, with expected improvement as the default. For multi-objective problems it supports Thompson sampling, hypervolume probability of improvement, and expected hypervolume improvement, with Thompson sampling as the default (Tamura et al., 14 Jun 2026).
Several methods target more specialized laboratory regimes. BOMP is intended for campaigns in which some process parameters must be shared across a batch. NTS searches for experiments exceeding a moving threshold based on the current best value, with aggressive, moderate, and conservative modes defined as $0.99$, $0.95$, and $0.9$ times the present best, respectively. COMBI is tailored to combinatorial composition-spread workflows and proceeds in three stages: identifying a promising composition point using Bayesian optimization, proposing a gradient of compositions between selected element pairs, and identifying the most informative element pair for the next campaign (Tamura et al., 14 Jun 2026).
NIMO also includes non-standard exploration modes. PTR maximizes the joint probability that candidate properties fall inside user-specified target ranges. BLOX is explicitly objective-free and uses Stein discrepancy with greedy batch selection to pursue novelty relative to the current training data. PDC is intended for categorical phase labels and combines graph-based semi-supervised learning with uncertainty sampling. RSVM learns from ordinal ranking rather than absolute numerical values and can use auxiliary ranking data from related systems for transfer learning. LLMEP replaces the numerical optimizer with a LLM and builds a detailed Markdown prompt containing chemistry context, objectives, measurements, and domain constraints (Tamura et al., 14 Jun 2026).
The algorithm portfolio therefore reflects a broad interpretation of “closed-loop experimentation”: optimization, phase mapping, ranking, target satisfaction, broad property-space coverage, and text-mediated planning all appear as first-class tasks.
4. NIMO Controller and MCP-mediated orchestration
“NIMO Controller” is an SDL orchestration framework built around the Model Context Protocol. Its governing design principle is that all SDL functionalities are exposed through MCP servers, making MCP the abstraction layer for the entire laboratory stack (Yoshikawa et al., 13 May 2026). Rather than binding a frontend directly to hardware APIs or Python libraries, the system treats laboratory hardware, robot functions, databases, and the NIMO decision engine as MCP tools.
At the architectural level, NIMO Controller acts as an MCP host between users and backend MCP servers. The frontend combines two interfaces in one application: a visual programming interface and a natural-language interface. One special backend server is the NIMO MCP server, which always stays connected and wraps the NIMO decision-making library. Additional component servers expose hardware and auxiliary SDL services (Yoshikawa et al., 13 May 2026).
The visual interface is built using Blockly. On page load, the frontend queries the registered MCP servers, discovers their tools, and automatically generates matching Blockly block definitions. The input schema of each tool determines the generated block’s input fields, while a core toolbox provides repeat and conditional blocks and a dedicated NIMO toolbox provides decision-making functions. Workflows can therefore be constructed by drag-and-drop without writing code. When executed, the workflow is sent to the backend, and the corresponding MCP servers are called in sequence. The interface highlights the currently executing block in real time (Yoshikawa et al., 13 May 2026).
The natural-language interface uses an LLM agent implemented with the OpenAI Agent SDK. The same MCP backend is exposed to the agent as callable tools. Tool invocations are not fully automatic by default: users approve or reject each requested call, though an auto-approve mode permits autonomous execution. This is the central interoperability claim of the controller: one standardized backend, two frontends, and no duplication of orchestration logic (Yoshikawa et al., 13 May 2026).
The NIMO MCP server exposes a specific optimization workflow. A user first uploads candidates.csv; the server then exposes parameter names, currently selected values, nimo.selection(), nimo.update(), and visualization tools that return graphical summaries as images. At the time of writing, only MCP tools are supported; MCP resources and prompts are not used. Tool outputs are displayed as text or images, and visual-programming input schemas are limited to basic Blockly-compatible types such as numbers and strings (Yoshikawa et al., 13 May 2026).
5. Deployments, validation, and no-code use
The NIMO platform paper reviews six SDL implementations driven by NIMO across electrolyte discovery, organic synthesis, thin-film exploration, fuel-cell process informatics, coffee-ring phase exploration, and legacy liquid-handling automation (Tamura et al., 14 Jun 2026).
| Implementation | System | NIMO role |
|---|---|---|
| NAREE | Automated robotic electrochemical experiments | Closed-loop electrolyte formulation and battery-performance evaluation |
| CHEMSPEED | Automated synthesis plus supercritical fluid chromatography | Bayesian optimization of Suzuki–Miyaura coupling conditions |
| COMBAT | Combinatorial sputtering platform | COMBI-driven thin-film exploration |
| ROPES | Robotic pilot line for catalyst-layer manufacturing | Optimization of process parameters |
| Coffee Ring SDL | Robotic arm, OT-2, hotplate, camera | PDC-based phase-diagram construction; IvoryOS interoperability demo |
| BioDot | Legacy Visual Basic-controlled precision dispenser | CSV-mediated integration with non-Python legacy software |
These examples illustrate different aspects of the platform’s scope. NAREE explored multi-component electrolyte formulations by selecting five additives from sixteen candidates in a combinatorial space of 4,368 combinations. CHEMSPEED demonstrates discrete-variable reaction optimization. COMBAT uses human-in-the-loop transfer steps. ROPES extends NIMO from composition discovery to process informatics. BioDot shows that legacy Windows software need not be rewritten for autonomous operation (Tamura et al., 14 Jun 2026).
To lower the barrier for non-programmers, the same paper introduces NIMO Desktop, a cross-platform GUI for Windows and macOS with separate Selection and Update tabs. The desktop application supports algorithm choice, candidate-pool and proposal-file specification, parameter entry, and writing results back to candidates.csv. Algorithms available there include RE, ES, DOE, PHYSBO, BOMP, NTS, PTR, BLOX, and PDC (Tamura et al., 14 Jun 2026).
The NIMO Controller paper validates MCP-based orchestration with a color-matching SDL built from a DOBOT Magician robotic arm, an electronic pipette, and a camera. Three dyes—red, yellow, and blue—are dispensed from a 6-well plate into a 12-well mixing plate, with a separate water dish for pipette-tip washing. The objective is to minimize the CIEDE2000 color difference to a user-specified target, implemented as maximization of the negated score
The search space is discrete: each dye ratio is divided into 20 levels from to in increments, and total dispensed volume is fixed at $2.0$ mL (Yoshikawa et al., 13 May 2026).
The closed loop has five steps: NIMO proposes dye ratios; the robotic arm dispenses and mixes; the camera measures the resulting color; the system computes the color difference; and the result is fed back into NIMO. Two validation targets were used: kikyou-iro (#6A4C9C) and ama-iro (#D6C6AF). Each run used four initial random samples followed by eight Bayesian optimization steps using PHYSBO, with each iteration taking about 12 minutes, mostly due to robotic liquid handling. The paper reports a consistent improvement trend in the best negated color difference over iterations, supporting the claim that the controller can deploy a complete closed-loop pipeline without client-side code (Yoshikawa et al., 13 May 2026).
6. Other meanings and terminological ambiguity
Outside autonomous experimentation, “NIMO” and closely related spellings denote unrelated concepts.
| Term | Expansion or role | Domain |
|---|---|---|
| NIMO | Nonlinear Interpretable MOdel | Interpretable machine learning |
| NiMo | Nets In Motion | Graphical functional dataflow programming |
| NiMo/Al0O1 | Sulfided hydrotreating catalyst designation | Catalytic upgrading of HTL biocrudes |
In machine learning, “NIMO” abbreviates Nonlinear Interpretable MOdel, an intrinsically interpretable hybrid model that preserves the global interpretability of linear coefficients while using a neural network to learn nonlinear multiplicative corrections (Xu et al., 5 Jun 2025). Its defining structure is
2
with the constraints that the network acts as a correction to the linear term, that 3 does not depend on 4, and that 5. Optimization uses profile likelihood so that, for fixed neural parameters, the linear coefficients can be updated analytically; adaptive ridge regression is used to incorporate sparsity. In this literature, NIMO has no connection to self-driving laboratories (Xu et al., 5 Jun 2025).
A visually similar but differently capitalized term, NiMo, expands to Nets In Motion and denotes a strongly typed graphical functional dataflow language based on a net of processes communicating through FIFO channels (Aráoz et al., 2015). The 2015 paper uses NiMo to express a two-round triangle-counting algorithm for graphs that do not fit in memory. Its main architectural claim is architecture-agnostic execution through dynamic scheduling rather than programmer-specified parallelization constructs. Again, this is unrelated to the materials-discovery platform (Aráoz et al., 2015).
In catalysis, NiMo/Al6O7 refers to a commercial pre-sulfided nickel–molybdenum on alumina hydrotreating catalyst rather than to any software or algorithm (Castello et al., 2019). The cited study uses this catalyst for upgrading hydrothermal liquefaction biocrudes from sewage sludge, Spirulina, and miscanthus, showing feedstock-dependent differences in hydrodeoxygenation, hydrodenitrogenation, coking, and product distributions.
A further possible confusion arises from a 2026 haptics paper whose term is NIMA, not NIMO: Nonlinear Impedance Matching Approach for force rendering in robotic laparoscopic surgery (Mazidi et al., 20 Jan 2026). This is a distinct acronym and not a separate NIMO variant.
Taken together, these usages show that “NIMO” is not a single transdisciplinary concept but a cluster of unrelated domain-specific names. In current arXiv literature, the most substantial recent usage is the autonomous-experimentation platform and decision engine for self-driving laboratories, but accurate interpretation depends on research context.