1 Introduction↩︎

With the rapid development of foundation models, Vision-Language-Action (VLA) models, imitation-learning policies, and related techniques, embodied agents are moving beyond simple manipulation skills toward the execution of complex laboratory procedures. Specifically, VLA models [1]–[3] enhance robots’ ability to generate actions from multimodal inputs; imitation-learning policies, such as ACT [4] and Diffusion Policy [5], improve the learning and execution of laboratory manipulation skills; and laboratory simulation platforms and robotic chemistry systems, such as LabUtopia [6], RoboChemist [7], and Organa [8]–[15], further establish scientific laboratories as an important evaluation setting for embodied agents. However, in laboratory environments, task success does not necessarily imply safe execution, since agents must also follow safety knowledge expressed in natural-language rules, manuals, protocols, and standard operating procedures, covering chemical compatibility, equipment usage, procedural ordering, and risk intervention.

Existing safety research for laboratory embodied agents falls into three lines. First, safety benchmarks test hazard recognition, risk assessment, unsafe-instruction refusal, and safety-aware planning, including LabSafety Bench, LABSHIELD, SafeAgentBench, VESTABENCH, and Safe-BeAl [16]–[21]. Second, decision-level methods improve planners or policies through safety-aware reasoning, alignment, and constrained learning, such as planning agents, risk-cognition modules, preference alignment, and constrained VLA optimization [13], [22]. Third, runtime enforcement methods use guardrails, executable predicates, code-based monitors, or control constraints to block, replan, or restrict unsafe actions during execution [23]–[26]. However, these works often assume safety information is already formalized. In laboratories, safety knowledge often appears as natural language, including SOPs, manuals, chemical-handling rules, and protocol instructions. How to ground such text into executable monitor specifications for controller-side checking remains under-characterized.

The challenge is not simply to convert text into structured fields, but to make human-readable laboratory safety knowledge enter the robot control loop. This requires a representable, learnable, and executable path from laboratory natural language to controller-side intervention, which raises three key questions. First, how should laboratory safety language be represented so that rules can be activated and checked by a controller? Second, how can models ground diverse sources, including SOPs, manuals, protocols, and chemical safety statements, into a typed executable representation? Third, how can the grounded representation be compiled into runtime monitors that check live laboratory state before robot actions and pass, modify, or block actions when necessary?

To address this problem, we propose LabGuard, a language-to-execution safety suite that transforms laboratory natural language into executable runtime guards for embodied laboratory agents. LabGuard includes three core components for executable representation, supervised annotation, and laboratory-language grounding. First, LabGuard-IR defines a typed executable representation, specifying the fields needed for runtime monitoring, including constraint type, entity binding, action scope, state predicates, severity, and intervention mode. Second, LabGuard-Bench provides 812 supervised annotations for training and evaluation, enabling systematic assessment of how well models recover executable fields from laboratory natural language. Third, LabGuard-Grounder maps natural-language laboratory rules into LabGuard-IR, turning human-readable safety knowledge into structured specifications that can be compiled. The resulting IR instances are then handled by the LabGuard Pipeline, which compiles them into executable runtime monitors and executes these monitors at the controller boundary, where proposed actions can be passed, modified, or blocked according to the live laboratory state. Experiments show that LabGuard generalizes to unseen laboratory-rule sources with 79.4 task-scope F1 and reduces unsafe events from 39.5% to 23.8% after monitor compilation. In LabUtopia, its ACT-integrated monitors keep interventions below 0.5% while preserving task success.

Our contributions follow the representable, learnable, and executable path introduced above. First, we propose LabGuard-IR, a typed representation that makes laboratory safety language controller-usable by capturing constraint type, entity binding, action scope, state predicates, severity, and intervention mode. Second, we construct LabGuard-Bench, which provides 812 supervised annotations expanded from 203 seed laboratory rules, and introduce LabGuard-Grounder, which maps natural-language laboratory rules into LabGuard-IR. Third, we develop and evaluate the LabGuard Pipeline, which compiles grounded IR instances into runtime monitors and integrates them with LabUtopia + ACT control to test hazard reduction, task preservation, and intervention overhead.

2 Related Work↩︎

LLM-based Embodied Agent Safety. Recent work on LLM-based embodied agent safety studies how agents recognize unsafe goals, refuse hazardous instructions, assess risk, or generate safety-aware plans [18], [27], [28]. These studies typically evaluate safety at the instruction or planning level, where the model is asked to judge whether a goal, instruction, or proposed plan is safe before execution. Related methods further improve decision-level safety through safety-aware reasoning, alignment, constrained learning, or risk-aware planning modules [28].

Runtime Assurance and Safety Filters for Robotics. Runtime assurance and safety-filtering methods aim to restrict unsafe behavior during execution by monitoring states, filtering actions, or enforcing formal constraints at the controller boundary. Classical approaches include control barrier functions and related safety filters that constrain robot actions with respect to predefined safe sets [25], [29]–[33]. Recent embodied-agent systems also use executable predicates, code-based monitors, visual monitors, or guardrail modules to inspect plans and actions before execution [23], [24], [34].

Natural Language Interfaces to Executable Systems. Semantic parsing maps natural language to executable formal representations such as SQL queries, robot commands, logical forms, and API calls [35]–[38]. In scientific domains, prior work has extracted structured actions, materials, and experimental operations from synthesis procedures or laboratory protocols [39], [40]. Recent structured generation methods further improve output validity through lexical constraints, neural logic decoding, grammar-based parsing, and schema-constrained generation [41]–[45].

4pt

3 LabGuard↩︎

3.1 Problem Formulation↩︎

Laboratory safety knowledge is often written in natural language for human practitioners, including SOPs, safety manuals, chemical handling rules, and protocol instructions, whereas runtime robot controllers require machine-checkable monitor specifications that can be activated, evaluated, and enforced during execution. As illustrated in Figure 1, this requires converting textual safety rules, such as chemical-incompatibility instructions, into typed executable specifications that can be checked against the current laboratory state and controller-proposed actions. We formalize this as a laboratory-language-to-monitor transformation problem: \[G_\theta(r)=z,\quad E(\operatorname{compile}(z),s_t,a_t)=v_t. \label{eq:sop95to95contract95problem}\tag{1}\] Here, \(r\) denotes a natural-language laboratory rule, \(G_\theta\) denotes the grounding model, \(z\) denotes the predicted executable safety specification, \(s_t\) denotes the live laboratory state, \(a_t\) denotes the controller-proposed action, and \(v_t \in \{\text{pass}, \text{modify}, \text{block}\}\) denotes the runtime safety verdict. Thus, the goal is not to generate a textual explanation of a safety rule, but to recover the structured execution semantics needed by a runtime monitor.

3.2 LabGuard-IR↩︎

We define LabGuard-IR as the typed executable representation used as the target of laboratory-language grounding and the input to runtime monitor compilation. It is designed to capture the execution semantics needed for controller-side safety checking, rather than only describing a rule in natural language. Given a natural-language laboratory rule \(r \in \mathcal{R}\), LabGuard-IR represents the grounded executable specification as \[z = (\hat{t}, \hat{S}, \hat{p}, \hat{T}, \hat{v}, \hat{i}). \label{eq:contract95ir}\tag{2}\] Here, \(\hat{t}\) denotes the constraint type, \(\hat{S}\) denotes the substance or entity set, \(\hat{p}\) denotes the state or action predicate, \(\hat{T}\) denotes the action scope, \(\hat{v}\) denotes the severity level, and \(\hat{i}\) denotes the intervention mode. Table ¿tbl:tab:ir95example? provides a field-level example of this representation, corresponding to the typed executable view in Figure 1 (b).

These fields jointly make the grounded rule executable:

3.3 LabGuard-Bench↩︎

LabGuard-Bench is a supervised benchmark for training and evaluating laboratory-language grounding, where each natural-language safety rule is aligned to an executable schema: constraint type, canonical substances, formal predicate, robot-task tags, severity, and intervention mode, so each annotation can be compiled into a runtime monitor. The corpus contains 203 seed canonical rules from four sources: laboratory safety manuals (71), PubChem GHS statements (62), expert-authored controller-facing rules (50), and chemical safety references (20), stratified by difficulty (easy 71, medium 105, hard 27). Seeds are expanded via paraphrase augmentation into 812 labeled examples. The 15 constraint types group into four families: material compatibility, physical/quantitative handling, process/equipment checks, and environment/PPE/waste. Every seed rule and paraphrase was independently reviewed by all five annotators with simple majority adjudication (\(\geq\)​3 of 5). Agreement distribution and review protocol are in Appendix 10.

3.4 LabGuard-Grounder↩︎

LabGuard-Grounder is the trainable component that maps natural-language laboratory rules into the LabGuard-IR defined in Eq. 2 . Given a supervised example \((r_i, z_i)\) from LabGuard-Bench, where \(r_i\) is a natural-language laboratory rule and \(z_i\) is the annotated executable specification, the grounder predicts \(\hat{z}_i = G_\theta(r_i)\). The predicted IR instance \(\hat{z}_i\) follows the same schema as LabGuard-IR and is later passed to the compiler if it satisfies schema validation.

In our implementation, each IR instance \(z_i\) is serialized as a structured text sequence, and the grounder is trained with supervised sequence generation. The objective is the negative log-likelihood of the gold IR sequence: \[{!}{ \mathcal{L}_{\mathrm{ground}} = -\sum_{i=1}^{N} \sum_{m=1}^{|z_i|} \log P_\theta(z_{i,m} \mid r_i, z_{i,<m}). } \label{eq:grounder95loss}\tag{3}\] This objective trains the model to recover the executable fields required for downstream monitor compilation, including constraint type, substance or entity binding, state predicate, action scope, severity, and intervention mode.

At inference time, \(\hat{z}_i\) is validated against the LabGuard-IR schema for required fields, categorical values, registry-resolved substances, and compiler-acceptable predicates. Valid IR instances are passed to the compiler, while invalid outputs are rejected or flagged. We implement the grounder with a LoRA fine-tuned language model and evaluate a hybrid variant with rule-based normalization for schema-sensitive fields such as substance mentions. Detailed training hyperparameters are provided in Appendix 14.

4 LabGuard Pipeline↩︎

Given a LabGuard-IR instance predicted by LabGuard-Grounder, the LabGuard Pipeline turns the structured representation into runtime safety behavior. The pipeline consists of two stages: monitor compilation and runtime monitor execution.

4.1 Monitor Compilation↩︎

We instantiate the \(\operatorname{compile}(\cdot)\) step introduced in Section 3.1. Given a grounded LabGuard-IR instance \(\hat{z}\) predicted by LabGuard-Grounder, the compiler lowers it into an executable runtime monitor: \[\rho = \operatorname{compile}(\hat{z}) = (f_{\mathrm{check}}, \phi_{\mathrm{scope}}, \theta, \hat{v}, \hat{i}). \label{eq:compile95monitor}\tag{4}\] Here, \(f_{\mathrm{check}}\) is a state-action check function, \(\phi_{\mathrm{scope}}\) determines when the monitor is active, \(\theta\) stores monitor parameters, \(\hat{v}\) is the severity level, and \(\hat{i}\) is the intervention mode.

The compiler constructs these monitor components from LabGuard-IR fields. The constraint type selects \(f_{\mathrm{check}}\) from a typed monitor library, e.g., mapping \(\mathrm{chemical\_incompatibility}\) to \(\operatorname{MaterialCompatibilityCheck}\). The action scope instantiates \(\phi_{\mathrm{scope}}\) so that the monitor is activated only for relevant controller actions. The substance/entity set and predicate populate \(\theta\) with registry-resolved substances, numeric thresholds, spatial bounds, or other check parameters. The severity and intervention fields determine the logging priority and the runtime response once a violation is detected.

Before producing a monitor, the compiler validates schema conformance, resolves registry entries, and checks whether the IR instance can be lowered to an implemented monitor. IR instances that fail these checks are rejected rather than executed. All accepted monitors expose the same interface, allowing heterogeneous constraint types to be activated and evaluated by the same runtime execution loop.

4.2 Runtime Contract Execution↩︎

LabGuard executes compiled monitors at the controller boundary and is agnostic to the underlying policy. At each control step, a base controller \(\pi\) proposes a raw action \(a_t^{\mathrm{raw}} = \pi(o_t)\), and the runtime executor uses the live laboratory state \(s_t\) to check whether this action satisfies the compiled monitors. Here, \(s_t\) denotes the live laboratory state, including per-container substance, volume, temperature, capacity, and robot kinematic state.

The executor first activates the monitors whose action scopes match the proposed action: \[\mathcal{R}_t = \{\rho \mid \phi_{\mathrm{scope}}^{\rho}(a_t^{\mathrm{raw}})=\mathrm{true}\}.\] Each active monitor then evaluates its check function against \((s_t, a_t^{\mathrm{raw}})\) and produces a verdict according to its intervention mode. Given the raw action, live state, and active monitor set, the safety filter returns the executable action: \[a_t^{\mathrm{safe}} = \operatorname{SafeFilter}(a_t^{\mathrm{raw}}, s_t, \mathcal{R}_t).\] The safety filter may pass the raw action unchanged, modify it, or block it before execution; all interventions and violations are logged for analysis.

In our implementation, \(\operatorname{SafeFilter}\) combines chemistry-state-aware semantic checks, a barrier-style action filter, and risk scoring. The semantic checks evaluate IR predicates over live container states, including incompatibility, overflow, temperature, sequencing, PPE, and waste handling; the action filter enforces workspace, joint-margin, and velocity bounds; and the risk scorer flags high-risk steps from velocity, proximity, chemical-hazard, and uncertainty signals. Full details are provided in Appendix 8.

5 Experimental↩︎

3.5pt

5.1 Experimental Setup↩︎

5.1.0.1 Benchmarks and evaluation settings.

We evaluate LabGuard across three stages, using both our constructed benchmarks and existing runtime environments. For laboratory-language grounding, we use LabGuard-Bench under source-held-out, random 80/20, and chemistry-held-out settings. For compiled-monitor replay, we construct a 100-scenario stress replay set with 70 unsafe scenarios and 30 safe-control scenarios across 7 hazard categories. For runtime monitor execution, we use LabUtopia Levels 1–4 with ACT as the base policy. We additionally use a controlled pour scenario for module ablation. Full benchmark and setting details are provided in Appendix 7, with runtime tasks and stress construction described in Appendix 12 and Appendix [app:stress95construction].

5.1.0.2 Metrics.

For laboratory-language grounding, we report Type Accuracy, Substance F1, Task Tag F1, Predicate Soft Match, Predicate Canonical EM, Schema Valid, and Compile Ready. For compiled-monitor replay, we report check-function accuracy, task-scope F1, parameter recovery, catch rate, precision, and F1 on unsafe and safe-control scenarios. For runtime monitor execution, we report Success Rate (SR), Violation Rate (VR), Intervention Rate (IR), Collision Rate (CR), mean Risk, Episode Length (EL), and Task Completion Time (TCT). Detailed metric definitions are provided in Appendix 9.

5.1.0.3 Baselines.

For laboratory-language grounding, we compare against a Regex baseline, prompted LLMs, LoRA fine-tuned models, and our hybrid grounding variant. For compiled-monitor replay, we compare monitors compiled from different grounding outputs, including Regex, LoRA, Hybrid, and gold labels / monitors compiled from gold labels. For runtime monitor execution, we compare Base, which uses ACT [4] without the safety layer, against different runtime module configurations. Full implementation details are provided in Appendix 14.

5.2 Laboratory-Language Grounding↩︎

We first evaluate whether LabGuard can ground natural-language laboratory rules into executable IR instances under distribution shift. Table 1 reports source held-out and chemistry-held-out results, while the random 80/20 split is reported in Appendix 11 as an in-distribution upper bound. LabGuard-Hybrid achieves the strongest performance, reaching 79.4 task-scope F1 under source-held-out evaluation and 91.8 under chemistry-held-out evaluation. This indicates that LabGuard can still recover when safety rules should be activated even when source families or chemistry categories change.

LabGuard-Hybrid is effective because it combines learned task-scope prediction with rule-based substance normalization. The learned component handles variation in laboratory-rule wording, while the rule-based component reduces substance-resolution errors that can prevent IR instances from compiling correctly. Although exact predicate recovery remains challenging, the grounded IR instances reduce unsafe events from 39.5% to 23.8% after monitor compilation under source-held-out evaluation. This suggests that accurate activation scope and reliable substance binding carry much of the downstream safety signal by routing proposed actions to the correct runtime checks.

5.3 Compiled-Monitor Replay↩︎

We next evaluate whether grounded IR instances can be compiled into deterministic monitors that prevent unsafe outcomes in offline replay. The stress set contains 70 unsafe scenarios across 7 hazard categories and 30 safe-control scenarios; among the unsafe cases, 54 are in-schema and executable by the current monitor library, while 16 require additional monitor types such as exothermic-reaction tracking. Gold IR labels catch all 54 in-schema unsafe scenarios, and LoRA and LabGuard-Hybrid approach this oracle bound, with remaining gaps mainly caused by grounding errors rather than monitor-compilation failures Appendix 13. The 16 out-of-schema cases are missed by all configurations, including gold, indicating a schema-coverage boundary rather than a translation failure. Table 3 further shows that source-held-out grounding preserves the relative ordering of methods after compilation, although cross-source degradation remains non-trivial.

3.5pt

2pt

We analyze how grounding errors propagate through the LabGuard pipeline and affect downstream execution. Grounding errors mainly concentrate in formal predicate composition, while task-scope grounding remains the most transferable signal under source shifts Table 3. This pattern reflects three factors: schema complexity from 15 heterogeneous constraint types, sparse supervision with only 3–5 paraphrases per canonical rule, and metric limitations where token-level Soft Match may miss semantically equivalent predicates such as “temp \(>\) 80” and “80 \(<\) temp”. Executable equivalence testing is left to future work Appendix 15)·.

The compiled pipeline remains effective because runtime safety depends heavily on correct task-scope routing. Once the system identifies when a rule should fire, deterministic check functions and registry-resolved substances recover much of the remaining execution semantics. LabGuard-Hybrid further reduces substance-extraction failures by using regex fallback for the substance slot. This explains why models with modest predicate scores can still yield measurable safety improvements after compilation.

5.4 Runtime Monitor Execution↩︎

The final stage closes the loop: compiled monitors must attach to learned controllers in a live simulator without degrading task success. We evaluate LabGuard on LabUtopia Levels 1–4 (per-task list in Appendix 12; full numbers in Appendix [app:runtime95full]) to demonstrate runtime feasibility and bound the overhead of compiled-monitor execution. The focus is on whether the safety layer can integrate with ACT policies without task-success loss; main-runtime VR/Unsafe Event are assurance-layer-logged (Appendix 9), while an outcome-level oracle independent of the wrapper is applied only to the controlled pour ablation (Table 4).

Figure 3 shows the safety layer is essentially a no-op on tasks already at ceiling and is associated with the largest task-success gains on safety-relevant operations. Intervention rates stay \(\leq 0.5\%\) across tasks, and assurance-layer-logged violations remain in the \(0.2\)–\(0.6\) range. This pattern confirms that compiled monitors do not introduce spurious interventions or degrade controller performance, completing the path from laboratory language to runtime monitoring without controller-side friction.

5.5 Runtime Module Ablation↩︎

We isolate the contribution of each runtime module using a controlled pour stress scenario that deliberately triggers unsafe behavior under a weak base policy. This offline-rescored ablation uses an outcome-level oracle independent of the runtime assurance layer, and Table 4 reports success rate (SR), intervention rate (IR), violation rate (VR), risk score, collision rate (CR), episode length (EL), and total cycle time (TCT). Full LabGuard improves SR from 10% to 40% and reduces logged violations from 2.8 to 0.6 per episode. Among individual modules, the Action Filter contributes the largest gain, raising SR to 30% and reducing VR to 0.9, while Planning and Semantic modules provide complementary violation reductions. Risk Scoring alone does not improve SR, but provides discriminative risk information for future adaptive interventions. Overall, the ablation shows that runtime safety comes from the combination of task-scope routing, chemistry-state-aware checks, and kinematic filtering rather than any single module.

2.2pt

6 Conclusion↩︎

We presented LabGuard, a language-to-execution safety suite that transforms laboratory natural language into typed executable specifications and runtime guards for controller-side intervention in simulation. By separating laboratory-language grounding, monitor compilation, and runtime execution, LabGuard provides an auditable path from human-readable laboratory safety knowledge to executable monitors. Through LabGuard-Bench and a three-stage evaluation protocol, we show that laboratory-language grounding and monitor compilation can link language-level safety rules to runtime robot behavior within a schema-scoped setting. Future work should expand the monitor schema, improve cross-source predicate grounding, and evaluate stronger safety guarantees beyond simulation.

Limitations↩︎

Our work is limited by its simulation-only evaluation. All runtime experiments and stress tests are conducted in the LabUtopia virtual environment, so the results show that LabGuard can connect laboratory natural language to runtime monitors in simulation, but they do not establish real-world laboratory safety. Physical deployment would require additional validation with real robot dynamics, sensing noise, calibration errors, and institutional safety procedures. A second limitation is broader policy coverage. We use ACT as the main learned controller in LabUtopia, which is sufficient to test whether compiled monitors can be inserted at the controller boundary. Future work can evaluate the same runtime-contract layer with more VLA models and manipulation policies to study how the safety layer behaves across different embodied agents.

Ethics Statement↩︎

This work is conducted entirely in simulation and does not involve deployment on physical laboratory hardware or interaction with real hazardous chemicals. As a result, the experiments do not create direct real-world safety risks during evaluation. At the same time, the paper studies safeguards for scientific robotics, so we intentionally avoid overstating claims to reduce the risk of misleading conclusions about real-world laboratory safety.

7 Evaluation Matrix↩︎

Table 5 summarizes the evaluation settings used in the main paper. We separate three kinds of evidence: laboratory-language grounding on held-out labels, offline replay of compiled monitors on scripted safety scenarios, and live LabUtopia execution with ACT. “Offline replay” means that compiled monitors are evaluated on scripted state traces; “live runtime” means that the safety layer runs inside the controller loop. This distinction is important because the stress benchmark uses outcome-level replay, whereas the L1–L4 runtime results report events logged by the active assurance layer.

3pt

8 Runtime Safety Module Details↩︎

This appendix gives additional implementation details for the runtime monitor execution modules summarized in Section 5.4. The modules operate after laboratory-language grounding and monitor compilation. No language model is invoked inside the controller loop.

8.1 Compiled Monitor Target↩︎

Given a grounded LabGuard-IR instance, \[\hat{z}=(\hat{t},\hat{S},\hat{p},\hat{T},\hat{v},\hat{i}),\] the compiler lowers it into a runtime monitor, \[\rho=\mathrm{compile}(\hat{z})=(f_{\mathrm{check}},\phi_{\mathrm{scope}},\theta,\hat{v},\hat{i}).\] Here, \(f_{\mathrm{check}}\) is the state-action check function, \(\phi_{\mathrm{scope}}\) determines whether the monitor is active for a proposed action, \(\theta\) stores monitor parameters, \(\hat{v}\) is the severity level, and \(\hat{i}\) is the intervention mode. The scope predicate is instantiated from the action-scope field: \[\phi_{\mathrm{scope}}(a)=\mathbf{1}[\mathrm{tag}(a)\in \hat{T}].\] The constraint type \(\hat{t}\) selects a monitor class from the typed monitor library, while \(\hat{S}\) and \(\hat{p}\) populate \(\theta\) with registry-resolved substances, thresholds, spatial bounds, or other check parameters.

For material-compatibility specifications, the monitor uses an incompatibility table over registered substances. For two substances \(c_a\) and \(c_b\), the lookup is \[\mathrm{compat}(c_a,c_b)= \begin{cases} 1, & c_b\notin\mathrm{inc}(c_a)\wedge c_a\notin\mathrm{inc}(c_b),\\ 0, & \mathrm{otherwise}, \end{cases}\] where \(\mathrm{inc}(\cdot)\) denotes the incompatible-substance list in the runtime registry. This lookup is intentionally simple. Violations are triggered by explicit registry entries and task-conditioned monitor templates, not by a symbolic planner or reaction simulator.

8.2 Chemistry-State-Aware Semantic Checks↩︎

The runtime assurance layer maintains a live laboratory state containing registered containers, their substance identities, volumes, temperatures, capacities, and the robot kinematic state. Active monitors evaluate their predicates against this state and the controller-proposed action.

For transfer-like actions, the monitor inspects the source container, destination container, transferred substance, destination contents, and planned transfer volume. The supported checks include incompatible mixing, destination overflow, temperature-threshold violations, sequencing preconditions, PPE-related preconditions, and waste-handling constraints. If a violation is detected, the monitor returns a verdict according to its intervention mode. The action may be blocked or modified before execution, and the intervention is logged for analysis. If no violation is detected, the state update is committed so that later monitors operate on the updated container state.

8.3 Geometric and Kinematic Bounds↩︎

The runtime layer also applies lightweight geometric and kinematic validation. These checks enforce fixed workspace bounds, conservative joint margins, and per-joint velocity limits. The workspace constraint is applied componentwise: \[p_{\min,k}\leq p_{ee,k}\leq p_{\max,k}, \qquad k\in\{x,y,z\},\] where \(p_{ee}\) is the end-effector position. The action-side velocity constraint is \[|\dot{q}_j|\leq \alpha \dot{q}_{j,\max}, \qquad \alpha=0.8.\] These bounds are fixed in the current implementation and are used as conservative runtime safeguards rather than learned safety constraints.

8.4 Barrier-Style Action Filter↩︎

The action filter uses barrier-style margins around joint limits together with velocity clamping. For joint \(j\), the margins are \[\begin{align} h_j^{+}(q) &= q_{j,\max}-q_j-\delta,\\ h_j^{-}(q) &= q_j-q_{j,\min}-\delta, \end{align}\] where \(\delta\) is a fixed safety margin. These quantities are used to steer target positions away from joint boundaries and to clamp velocities. Although the design is inspired by control-barrier constraints, the implementation does not solve a quadratic program and does not claim the guarantees of a full optimization-based CBF controller.

8.5 Risk Scoring and Logging↩︎

The risk scorer aggregates velocity, proximity, chemical hazard, and uncertainty with fixed hand-designed weights: \[\rho_t = 0.25\rho_v + 0.25\rho_p + 0.30\rho_c + 0.20\rho_u.\] The coefficients are fixed heuristics rather than learned parameters. When chemistry-state-aware checks are enabled, the chemical term \(\rho_c\) is computed from the live container state, including substance identities, volumes, fill fractions, and temperature-related signals. High-risk steps are logged for analysis, and threshold exceedances can produce safety events according to the active monitor configuration. In the current implementation, risk scoring is primarily diagnostic: it flags high-risk states and supports intervention analysis, but it does not by itself provide a formal safety guarantee or restore simulator state.

9 Runtime Metric Definitions↩︎

We report runtime metrics under two scoring modes. For L1–L4 LabUtopia runs, safety events are logged by the runtime assurance layer when that layer is active. For the controlled pour ablation, we additionally rescore each trajectory with an offline compiled-monitor checker, so that the Base policy, which has no active safety layer, can be compared with the safety-module variants.

9.0.0.1 Success Rate.

SR is the fraction of episodes that complete the task. Higher SR indicates better task performance.

9.0.0.2 Violation Rate.

VR is the average number of safety violations per episode. In the L1–L4 runtime table, VR counts violations logged by the active assurance layer. In the controlled pour ablation, VR is computed by replaying each trajectory through the same compiled-monitor checker. This offline scoring makes the Base row comparable to rows with an active safety layer.

9.0.0.3 Intervention Rate.

IR is the fraction of controller steps in which the safety layer blocks, modifies, or replaces the proposed action. It measures how often the runtime layer changes controller behavior. Lower IR is preferable when safety outcomes are comparable.

9.0.0.4 Unsafe Events and False Interventions.

Unsafe Event is reported for runtime-style summaries as the percentage of episodes in which the scoring protocol observes an unsafe outcome. In offline replay settings, the analogous outcome-level quantities are reported as catch, precision, and F1. False Intervention measures interventions on safe-control cases or safe execution segments, and is reported only when such safe-control labels are available.

9.0.0.5 Risk, Collision, and Runtime Cost.

Risk is the mean heuristic risk score from the runtime scorer. CR is the average number of collision events per episode in the controlled ablation. EL is the episode length in control steps, and TCT is the total cycle time. These quantities are reported in the controlled ablation to describe side effects of each runtime module.

10 LabGuard-Bench Construction Protocol↩︎

10.1 Annotation Protocol↩︎

The corpus starts from 203 seed rules from four source families described in Section 3.3. Each seed is labeled with constraint type, canonical substances, predicate, task tags, severity, and intervention mode. Paraphrases inherit the seed label only after review for semantic equivalence.

Five annotators with chemistry or robotics background reviewed the seed labels and paraphrases. Final labels use simple majority agreement. Items without majority agreement are revised before inclusion. This protocol is intended to keep paraphrase augmentation from adding or removing safety constraints.

We keep source-family metadata for each item and do not rely on verbatim source text in the released labels. Table 6 reports the final distribution over the 15 constraint types. The counts sum to 812 examples. Per-source seed counts are 71 lab-manual rules, 62 PubChem GHS statements, 50 expert-authored controller-facing rules, and 20 chemical-safety reference rules.

4pt

For source-held-out evaluation, all seed rules and paraphrases from the held-out source family are removed from training. Chemical names and constraint types can still appear across folds because they belong to the shared schema and registry. The split is therefore designed to test source phrasing and rule-structure shift, not unseen chemistry vocabulary alone.

4pt

11 Grounding Split Details↩︎

The random 80/20 split uses seed 42 over the 812-example LabGuard-Bench corpus. It can share source family, vocabulary, and paraphrase neighbors between train and test, so we treat it as an in-distribution upper bound. The source-held-out split is the main cross-source protocol for laboratory-language grounding.

8pt

11.1 Source-Held-Out Per-Fold Breakdown↩︎

Table 9 reports the four folds used in the source-held-out protocol. The main table reports the corresponding mean and standard deviation.

3pt

12 Runtime Evaluation Details↩︎

The ACT base policy follows the standard ACT setup used in the main runtime experiments. It uses two RGB camera views at \(256{\times}256\) resolution and robot state, and each task model is trained from roughly 50 scripted demonstrations. This small demonstration budget is one reason the runtime results have high variance on long-horizon or safety-sensitive tasks.

We evaluate on LabUtopia Levels 1–4. Level 1 includes pick, place, press, shake, stir, open, close, and pour. Level 2 includes HeatLiquid, PourLiquid, ShakeBeaker, and TransportBeaker. Level 3 uses OOD versions of press and HeatLiquid. Level 4 uses CleanBeaker. Each task is evaluated with 3 random seeds and 10 episodes per seed. Table 10 gives the per-task results.

8pt

13 Replay and Stress Benchmark Details↩︎

Table 11 reports replay diagnostics on 41 held-out rules and 80 scripted scenarios. These diagnostics use random-split grounding checkpoints, so they should be read as an in-distribution replay setting rather than the source-held-out operating point.

3pt

The stress benchmark contains 70 unsafe scenarios and 30 safe-control scenarios. The unsafe cases cover seven categories with 10 scenarios each. Table 12 reports true positives for unsafe categories and false positives for safe controls.

3pt

Stress scenarios are constructed to match the categories used in Table 2. Safe controls preserve surface features of unsafe cases while removing the violation. The replay evaluator runs compiled monitors on scripted state traces and records whether the unsafe outcome is caught.

3pt

14 Implementation Details↩︎

The LoRA laboratory-language grounding module uses Qwen3-8B as the base model. We train with rank \(r{=}16\), alpha \(\alpha{=}32\), target modules q_proj, k_proj, v_proj, and o_proj, 3 epochs, batch size 8, AdamW, learning rate \(2{\times}10^{-4}\), fp16 precision, and gradient accumulation of 4 steps. Decoding is greedy with temperature 0 and a maximum of 512 new tokens.

The regex baseline uses keyword scoring for the 15 constraint types, a curated chemical-name dictionary for substance extraction, template rules for task tags, and template instantiation for predicates. It has no learned component.

15 Future Predicate Evaluation Protocols↩︎

Current token-level metrics do not fully capture executable semantic equivalence. Future evaluations should compare predicates after normalization or by execution.

15.1 Canonical AST Exact Match↩︎

Predicates can be normalized before comparison.

• Reorder commutative operands: \([\mathrm{HCl}, \mathrm{H_2SO_4}] \equiv [\mathrm{H_2SO_4}, \mathrm{HCl}]\)

• Normalize comparison direction: \(\textit{temp} > 80 \equiv 80 < \textit{temp}\)

• Standardize variable names: \(\mathrm{temperature}(\mathrm{beaker}) \equiv \mathrm{temp}(\mathrm{container})\)

15.2 Executable Equivalence Testing↩︎

Synthetic states can be used to compare predicate truth values.

states = generate_test_states(
    rule_context)
for state in states:
    assert (eval(gold_pred, state)
        == eval(pred_pred, state))

15.3 Slot-Level Recovery↩︎

Slot-level recovery can separately measure substances, numeric thresholds, operators, scope tags, and directionality. This would show which predicate fields cause grounding failures.

References↩︎

---

1.   Equal contribution.↩︎

2. Corresponding author.↩︎