Source-linked AI summary
Making Self-Driving Laboratories Auditable:A Unified Framework for Hybrid Actions,Measurements, and Safe Execution
Zihan Zhang, Zeyu Wu, Xin Zhang, Mingyu Luo, Haohui Que, Tong Zhu
TL;DR
SDLs couple planning, automated execution, and measurement feedback, but integrating flexible robot control with instrument APIs and continuous measurements remains an execution-interface challenge. The paper proposes a traceable framework linking hybrid actions, device execution, safety monitoring, and episode-level evaluation. Its outcome is a proposed end-to-end design; the supplied passages report no completed benchmark validation.
Problem
Integrating flexible robot control with typed instrument APIs and continuous measurements remains an execution-interface challenge in self-driving laboratories.
Source: §1 · p. 1Method
The paper proposes LAM for measurement-conditioned hybrid actions, OpenSDL for device coordination and causal event records, Safe-SDL for runtime gating, and L3-Bench for episode-level evaluation.
Source: §1 · p. 2Results
The paper presents a proposed end-to-end design linking hybrid action generation, monitored device execution, measurement feedback, and experimental evaluation, rather than completed empirical validation.
Source: §1 · p. 2Takeaways & Limitations
The framework specifies how action proposals, device execution, safety decisions, and evaluation records can be linked for traceable SDL workflows.
Source: §1 · p. 2The work focuses on implementable and measurable L3 behavior, leaves L4 batch-level hypothesis optimization for future work, and leaves POMDP transition and reward models unspecified in the current implementation.
Source: §2.1 · p. 2, §2.2 · p. 3
Abstract
from arXiv · showhide
Self-driving laboratories (SDLs) are laboratory systems that couple experimental planning, automated execution, and measurement feedback in a closed loop. Integrating flexible robot control with the typed application programming interfaces (APIs) and continuous measurements exposed by laboratory instruments remains an execution-interface challenge. To address this challenge, we propose a traceable framework comprising four components: LAM (Lab Action Model), OpenSDL, Safe-SDL, and L3-Bench. LAM is a proposed measurement-conditioned policy architecture that extends vision-language-action paradigms to generate both continuous robot trajectories and typed instrument API calls. OpenSDL is an execution substrate with an initial control implementation, designed to map role-level operations to heterogeneous devices, coordinate execution, and record timestamped causal events. The proposed Safe-SDL runtime gate combines pre-dispatch schema and resource checks with signal temporal logic monitoring during execution, including extended waiting periods. L3-Bench (Level-3 Laboratory Benchmark) specifies an episode-level evaluation protocol covering physical outcomes, timing, reproducibility, safety violations, and fault recovery. Together, these components provide an end-to-end design for linking hybrid action generation, monitored device execution, measurement feedback, and experimental evaluation, addressing coordination and traceability challenges in SDL workflows.
1 Introduction
SDLs close the loop between experimental planning, automated execution, and measurement feedback, but integrating robot control with instrument APIs and measurements remains an execution-interface challenge. The paper proposes a traceable framework connecting hybrid action generation, monitored execution, and episode-level evaluation.
1 Introduction
- SDLs couple experimental intent and planning to automated execution and measurement feedback in a closed loop, supporting systematic trials with less repeated manual intervention.Practical systems combine planning, device control, sensing, data acquisition, analysis, and decision-making, with provenance management and human oversight.Source: §1 · p. 1
- Existing provenance approaches establish representation and consistency rules, while this framework targets their coupling to measurement-conditioned hybrid actions, pre-dispatch gating, clock-aware timestamps, and timed safety monitoring.SDL-Traj is proposed as a PROV-O-aligned laboratory profile; explicit vocabulary mappings, PROV-O export, SiLA 2 adapters, and conformance tests remain implementation targets.Source: §1 · p. 2
- The framework proposes LAM for hybrid robot trajectories and typed instrument calls, OpenSDL for coordinating heterogeneous devices and recording causal events, Safe-SDL for runtime gating, and L3-Bench for episode-level evaluation.LAM and the runtime components are proposed; OpenSDL has an initial control implementation.Source: §1 · p. 2
- OpenSDL is designed to map role-level operations to heterogeneous devices, coordinate dependencies and waiting requirements, and link measurements, device states, commands, and runtime decisions in timestamped causal records.Updated observations and confirmed events provide context for subsequent LAM proposals.Source: §1 · p. 2
- End-to-end LAM training, cross-device transfer experiments, and systematic hardware and safety validation remain incomplete; throughput, adaptability, and fault-recovery improvements are hypotheses for evaluation.Safe-SDL is proposed to check schemas and resources before dispatch and monitor temporal constraints during execution, including extended waits.Source: §1 · p. 2
2 Problem Formulation and Control Interface
The section formalizes laboratory control as measurement-conditioned decision-making over hybrid robot and instrument actions, with events recorded for causal replay. It specifies interface invariants and research questions for evaluating adaptation, coordination, safety, substitution, and reproducibility.
2.1 Autonomy Levels
- The paper adopts a task-specific L1–L4 autonomy classification, focuses on implementable and measurable L3 measurement-conditioned adaptation, and leaves L4 batch-level hypothesis optimization for future work.L1 denotes scripted execution or teleoperation; L2 visual protocol execution; L4 includes multiinstrument coordination.Source: §2.1 · p. 2
2.2 Hybrid State–Action and Event Semantics
- The laboratory process is represented as a POMDP because physical state is incompletely observed; the current implementation leaves transition and reward models unspecified.Observations combine synchronized visual frames, proprioception, and measurements from heterogeneous instruments.Source: §2.2 · pp. 2–3
- The action space combines continuous robot trajectories with typed instrument calls, which may be empty during monitoring or waiting and must satisfy resource and safety constraints.Robot actions include a no-motion option, while instrument calls identify a role, operation, and validated parameters with units.Source: §2.2 · p. 3
- Instrument-call semantics include a role, operation, parameters, waiting policy, and idempotency key; compilation checks units, ranges, resource locks, and preconditions before device mapping.Role-preserving substitution retains high-level action labels, but calibration, latency, and physical limits still require compatibility tests.Source: §2.2 · p. 3
- A timestamped event ledger links observations, candidate actions, and device returns to episode IDs and causal parents, recording clock offsets and drift because receive order alone cannot establish cross-device causality.Replay can distinguish an incorrect proposal, a safety-blocked action, and a device execution failure.Source: §2.2 · p. 3
2.3 Design Requirements
- Five interface invariants require semantic portability, composable actions, temporal consistency, safety gating, and replayability across shared timestamps, resource requirements, completion signals, and episode-linked records.Device interlocks govern actions independently of model confidence.Source: §2.3 · p. 3
- LAM proposes candidate actions while OpenSDL checks their semantic, temporal, and safety properties, with module exchange limited to a versioned schema; manual satisfaction of an invariant must be reported in evaluation.The invariants define an auditable protocol contribution and establish module boundaries.Source: §2.3 · p. 3
- The evaluation asks whether measurement tokens improve adaptation, concurrent hybrid dispatch reduces completion time under resource constraints, runtime gating contains faults and supports recovery, and role-preserving substitution maintains semantics and replay reproducibility.The questions also include the throughput cost of runtime gating.Source: §2.3 · p. 3
3 LAM: Lab Action Model
LAM is a proposed policy interface that combines measurement-conditioned robot trajectories with typed instrument calls. Its architecture, decoding, training objectives, and data splits are specified, while model training remains pending.
3.1 Model Structure and Multimodal Context Construction
- The proposed LAM architecture uses a shared multimodal context for a continuous motion expert and a discrete function-calling head, with an optional next-measurement prediction head.The context includes task language, visual information, trajectory history, and device states; the heads produce trajectory chunks and typed calls.Source: §3.1 · pp. 3–4, Figure 1 · p. 4
3.2 Hybrid Action Decoding and Uncertainty Handling
- LAM resolves continuous trajectories and typed instrument calls into an executable subgraph, while low confidence or stale telemetry can trigger read-only operation, human confirmation, or safe degradation.The scheduler inserts barriers for resource conflicts; read-only measurements and workspace-independent actions may overlap with robot trajectories.Source: §3.2 · pp. 4–5
3.3 Measurement-Conditioned Training Objective
- Fixed unit and channel scaling preserves absolute measurement magnitudes; flow-matching and call-token training objectives are specified, but model training remains pending.Optional consistency and safety-supervised losses remain extensions requiring specified labels, differentiable definitions, and ablations.Source: §3.3 · p. 5
3.4 Data Curation and Splits
- Data partitions group entire experimental batches, and evaluation covers nominal operation, measurement shift, device transfer, and fault injection.Device-transfer tests hold out the target provider; the concurrency ablation uses matched task instances and seeds with fresh policy rollouts.Source: §3.4 · p. 5
4 OpenSDL: Unified Infrastructure and Runtime Safety
OpenSDL combines a control substrate and proposed research interfaces for device routing, causal records, coordination, safety monitoring, and reproducible evaluation. The design links synchronized observations and gated actions to replayable benchmark reports and artifact manifests.
4.1 Unified Research Infrastructure
- The implemented OpenSDL substrate provides a Rust control engine, device transports and adapters, and a SQLite store; proposed extensions add trajectories, role contracts, and causal safety records.The proposed event model links observations and decisions across simulation, hardware-in-the-loop evaluation, and hardware.Source: §4.1 · p. 5
4.2 Role, DeviceProvider, and Event Ledger
- Role contracts validate calls against provider capabilities, while the proposed causal ledger records lifecycle events and supports dry-run, digital-twin, or allowlisted hardware replay.The ledger links events through causal parents and timestamps; replay differences from sampling, clock drift, or device noise are categorized in reports.Source: §4.2 · p. 6
4.3 Temporal Coordination and Runtime State Machine
- The scheduler resolves action-graph resource conflicts and dependencies before dispatch, using a prepare-and-dispatch protocol and provider-supported retry, compensation, or abort after failure.Physical reversibility depends on the device and operation; potentially irreversible actions remain explicit in evaluation and human approval.Source: §4.3 · p. 6
4.4 Safe-SDL Runtime Gating
- Safe-SDL monitors normalized temporal robustness and data validity; stale or invalid inputs, heartbeat loss, or insufficient robustness trigger blocking and a configured safe response.Monitoring remains active during waits, while hazards outside the specified constraints require separate controls and human approval; L3-Bench calls for labeled fault injection and joint records of gate decisions, device feedback, and overrides.Source: §4.4 · p. 7
4.5 Closed-Loop Execution Algorithm
- The closed-loop algorithm synchronizes observations, monitors safety, builds context, proposes and gates actions, logs decisions, dispatches approved candidates, and records returns and checkpoints.Dispatch requires durable proposal and gate logging; deadlines and retry budgets terminate stalled episodes, and recovery depends on provider capabilities.Source: §4.5 · p. 7
4.6 Reproducible Research Loop
- The reproducible research loop evaluates held-out cases through seeded digital-twin rollouts and optional hardware-in-the-loop runs, then exports benchmark reports with configuration, seed, asset, and log manifests.The same schema and event ledger connect the research and runtime lanes.Source: §4.6 · p. 8
4.7 Artifact Manifest and Release Tiers
- The proposed run manifest binds episodes to code, schema, model, provider, calibration, asset, seed, fault, and event-log records; release tiers distinguish simulation, HIL, and permitted physical-device artifacts.Restricted protocols use simulated substitutes, and each result identifies its release tier and limitations.Source: §4.7 · p. 8
5 L3-Bench and Evaluation Plan
L3-Bench evaluates complete laboratory episodes across physical outcomes, time, safety, and reproducibility. Its protocol defines scenario families and controlled comparisons, with reproducibility requirements for release evidence.
5.1 Metrics and Evaluation Protocol
- The protocol pairs physical and safety metrics with diagnostics, including mass-transfer error, dispensing uniformity, temperature-control measures, replay checks, and equivalence testing.Uniformly incorrect dispensing can still have low variation, so mean and target-volume error accompany CV; thresholds are pre-registered against device precision and protocol.Source: §5.1 · p. 8
- Complete episodes—not individual grasps or API calls—are the evaluation unit, ending in completion, rollback, or safe termination.Primary endpoints are normalized yield Y, temporal safety violation rate SVR, and time cost C; intervention penalties and failed or aborted episodes are retained under specified reporting rules.Source: §5.1 · p. 8
5.2 Scenarios and Comparative Evaluation
- Adaptive dilution, measurement-conditioned titration, and fault injection with recovery define the scenario families, evaluated under nominal, measurement-shift, device-transfer, and fault-injection conditions.Comparisons include a vision-only single-arm policy and LAM without measurement tokens against the full LAM × OpenSDL framework.Source: Figure 2 · p. 9, §5.2 · p. 9
- Controlled ablations isolate measurement tokens, concurrency, runtime-ledger integration, and the Safe-SDL gate; gate-disabled evaluation is restricted to simulation or risk-assessed HIL.Paired analyses preserve batch clustering and stratify results by task, device, and fault type; reports include uncertainty and worst-case quantiles.Source: §5.1 · p. 9, §5.2 · p. 10
5.3 Current Status and Reproducibility Checklist
- The reproducibility checklist requires versioned configurations, calibrations, seeds, complete event records, and scripts that regenerate summaries and run schema, provider, and replay checks.Dry-run or simulated replay results must identify hardware conditions they leave untested.Source: §5.3 · p. 10
6 Discussion and Limitations
The proposed interface must jointly represent hybrid actions, waiting, and safety constraints across laboratory settings. Its benefits remain hypotheses requiring systematic validation, and the architecture has explicit scope boundaries.
6 Discussion and Limitations
- The framework poses falsifiable hypotheses about measurement-shift adaptation, concurrency, fault handling, and provider substitution with replay; end-to-end training and episode-level evidence remain necessary to establish them.Failures should be attributed to representation, scheduling, providers, devices, or statistical protocols.Source: §6 · p. 10
- The target runtime combines schema validation, least-privilege providers, heartbeats, STL monitoring, and human oversight, but SQLite logging needs added controls for integrity under privileged modification.Complete sensor failures, unknown chemical reactions, and hazards outside the formalized model require safe termination; safety certification is outside the architecture's scope.Source: §6 · p. 10
- External validity for chemical and biological L3/L4 tasks, protocol-dependent yield, STL coverage, and reduced concurrency under shared workspaces or irreversible reactions require further experiments.Public releases should use hashes, interfaces, and sanitized substitutes for restricted protocols, sensitive processes, and industrial models.Source: §6 · p. 10
7 Conclusion
The conclusion presents LAM × OpenSDL as a research foundation connecting hybrid laboratory actions, execution infrastructure, and episode-level evaluation. Its throughput, adaptability, and safety benefits still require systematic validation.
7 Conclusion
- LAM conditions continuous motion and instrument actions on shared observations and typed measurement tokens carrying units, timestamps, and quality flags.Its action graphs make dependencies, resource use, waiting, and completion conditions explicit.Source: §7 · p. 11
- OpenSDL's initial substrate provides device routing, protocol adapters, transports, and SQLite logging, while proposed contracts add role-level portability and causal records.Safe-SDL specifies pre-dispatch checks and continuous monitoring with conditional recovery; L3-Bench defines episode-level reporting of physical outcomes, timing, safety, and reproducibility.Source: §7 · p. 11
- Throughput, adaptability, and safety benefits remain to be validated through training, ablations, hybrid scheduling, cross-device transfer, and controlled fault injection.Planned comparisons use fixed configurations, seeds, and calibration conditions, reporting failures, human interventions, and recovery costs.Source: §7 · p. 11
A Illustrative Role Descriptor
The role descriptor illustrates a provider-independent description of device capabilities and safety ranges. The same descriptor can support automated compatibility and failure-mode tests.
A Illustrative Role Descriptor
- The semantic role descriptor separates device capabilities and safety ranges from provider internals, allowing different providers to compile the same calls.Concrete providers may map calls to serial registers, network APIs, or HIL simulators.Source: A Illustrative Role Descriptor · p. 12
- The example heater role lists operating ranges, stable-for completion, returned measurement metadata, a resource, rollback behavior, and a simulator provider.These fields are shown in the illustrative role descriptor.Source: A Illustrative Role Descriptor · p. 12
- A tester can generate schema-validity, out-of-range parameter, timeout, and rollback tests from the descriptor.This makes device substitution a provider-compatibility question that can be checked automatically.Source: A Illustrative Role Descriptor · p. 12
B Failure Taxonomy and Labeling
The taxonomy assigns failed or aborted episodes a primary execution-failure label, with optional secondary labels, and separately tracks reconstruction failure. Primary labels identify the first causal event preventing normal completion.
B Failure Taxonomy and Labeling
- REPLAY separately flags reconstruction failure, including when an episode physically completed.Source: B Failure Taxonomy and Labeling · p. 12
- Table 4 is the episode-level analysis taxonomy for failure labels.Source: Table 4 · p. 12
- The primary execution-failure label identifies the first causal event that prevents normal completion; later faults are secondary, and compensating actions remain in the event ledger.This rule avoids misreporting safety interception as device failure and keeps rollback cost from being hidden in model retry counts.Source: B Failure Taxonomy and Labeling · p. 12
C Reproducible Release Checklist
The release checklist makes reproducibility a joint requirement: software, physical configuration, and episode evidence must be reconstructable together. It specifies what to record, which checks to run, and how to regenerate results.
C Reproducible Release Checklist
- Reproducibility requires reconstructing the software, physical configuration, and episode evidence together.The checklist serves as a concrete release gate.Source: C Reproducible Release Checklist · p. 12
- Record repository commits, schema versions, interface contracts, model checkpoint hashes, device inventories, calibration files, units, clock offsets, and asset and provider versions.Source: C Reproducible Release Checklist · p. 12
- Record task scripts, safety formulas and thresholds, random seeds, sampling temperature, and inference batch size.Source: C Reproducible Release Checklist · p. 12
- Retain synchronized observations, proposed and dispatched actions, device returns, event-ledger indices, operator overrides, and termination labels.Source: C Reproducible Release Checklist · p. 12
- Run schema validation, provider compatibility, dry-run, sim-replay, and hardware-replay tests when devices are available; regenerate tables and figures from manifests with versioned scripts.Report unavailable hardware or sanitized proprietary providers explicitly.Source: C Reproducible Release Checklist · p. 12
Declarations
The declarations describe planned release materials and restrictions, state the ethical and deployment conditions, and report authorship, competing interests, funding, and AI assistance.
Declarations
- The planned public release includes versioned code, releasable schemas, example configurations, figures, and sanitized trajectories; commercially restricted provider, calibration, and raw-device data are represented by interfaces, hashes, or simulated substitutes.Episodes supporting reported numbers must include a manifest, event-log index, and data-processing scripts.Source: Declarations · p. 12
- The work uses no human or animal subjects or personal data, while physical deployment must follow institutional rules for chemicals, biosafety, pressure vessels, and device interlocks.Safe-SDL provides software-level gating; institutional approval and on-site training remain required.Source: Declarations · p. 12
- The authors jointly developed the problem formulation, system architecture, OpenSDL interface design, evaluation protocol, and manuscript, and declare no directly related competing interests.Source: Declarations · p. 12
- Funding sources and grant numbers are listed in the Acknowledgments; AI-assisted tools were used for language editing, format conversion, and selected figures, with authors responsible for checking the final submission.Source: Declarations · p. 12