PaperlayerView exact revision on arXiv

Source-linked AI summary

A computable representation of the physical laboratory enables verifiable workflows

Xiaobo Li, Luyao Ge, Xiaohui Li, Lulu Guo, Ming Mao, Jiwang Zheng, Wenting Guan, Xin Yang, Yi Luo, Jun Jiang, Linjiang Chen

arXiv:2609.03621v1cs.AI

TL;DR

Agentic laboratories need a computable representation that connects unconstrained scientific intent with physically admissible operations and evolving laboratory states. This paper combines typed research objects, capability-bound operations, compositional workflows, and stateful simulation, and demonstrates four generated workflows that passed structural and state checks without mandatory errors or advisory warnings.

Abstract

from arXiv · show

Making science computable requires representations of both scientific knowledge and the physical world in which scientific claims are tested. A computable representation of the physical laboratory is established through typed research objects, capability-bound operations and a compositional workflow algebra. It provides the physical-world counterpart to machine-readable knowledge, expressing workflows as programs over evolving laboratory states with explicit dependencies, decisions, iteration and concurrency. The representation was implemented in a modular agentic robotic laboratory by binding formal operations to executable Function Skills. For diverse scientific intents, capability-relative workflows were generated, while stateful simulation propagated object transformations and verified operation preconditions and laboratory constraints before dispatch. The proposed representation and its engineering framework jointly establish a general computational interface between agent reasoning and capability-bound physical transformations, providing a foundation for end-to-end autonomous scientific discovery.

A computable laboratory state–action space … Supplementary Note 1. Typed research-object representation

The paper defines a typed, capability-bound representation of laboratory state and executable workflows, then operationalizes it through Function Skills, stateful simulation and validation. Four generated workflows demonstrate capability-relative composition and pre-dispatch verification, while the framework’s claims remain bounded by encoded contracts and simulation fidelity.

Research-object and operation representation

Workflows as compositional programs

Engineering executable semantics

  • The implementation compiled 49 workstation specifications into 63 agent-readable Function Skills and admitted generated Python workflows through allow-listed abstract-syntax-tree analysis before stateful simulation.The validate-then-commit cycle evaluates encoded conditions, commits successful object-state changes and localizes failures for workflow revision.Source: Engineering executable semantics · p. 3, Figure 2 · p. 4, Capability compilation · p. 6

Case construction and evaluation

Capability-relative generation from scientific intent

A representation layer for agentic laboratories

  • The contribution unifies typed physical research objects, an algebra of capability-bound transitions and executable checking, while limiting validity to encoded contracts and simulated state.Scheduler isolation, telemetry, device faults, repeatability and chemical outcomes require execution evidence or additional models; no wet-laboratory outcomes or inferential statistics were reported.Source: A representation layer for agentic… · p. 5, Statistical analysis · p. 7, Data availability · p. 7

A computable laboratory state–action space

Workflow composition

  • Five recursively nestable operators encode sequence, bounded iteration, evidence-dependent branching, conflict-checked parallel fork–join and contiguous protected execution.Type compatibility, finite loop bounds, unique branch selection, non-conflicting writes and declared ordering are checked computationally.Source: Figure 1 · p. 2, Workflow composition · p. 6

Supplementary Note 2. Primitive operation contracts

Primitive operations are formalized as preconditioned state transitions whose outputs remain compatible with subsequent operations. Function-Skill interfaces expose these contracts, while simulation enforces typed parameters, constraints, state changes, and failure handling before acceptance.

  • Each primitive operation applies an argument-dependent state transition only when its precondition evaluates to one, with outputs restricted to the next operation’s accepted domain.This contract defines operation admissibility and composability.Source: Supplementary Note 2. Primitive… · p. 12
  • Function-Skill declarations bind operations to workstations through typed arguments, constraints, state changes, structured returns, and declared failure categories.Namespaces encode workstation ownership, while explicit types, unit-bearing names, Literal aliases, named data classes, and centralized shared limits reduce ambiguity.Source: Supplementary Note 2. Primitive… · p. 12
  • The simulator performs parameter, precondition, and state-transition checks, keeping the callable interface separate from its executable implementation.Function-Skill documents contain only the callable contract, whereas simulator.py performs validation and state updates.Source: Supplementary Note 2. Primitive… · p. 12
  • MUST-rule failures populate SimState.errors and block acceptance, whereas SHOULD-rule failures create warnings; state changes commit only after all MUST rules pass.Data-producing operations additionally return typed result objects with file or measurement references.Source: Supplementary Note 2. Primitive… · p. 12
  • The runtime enumerates 11 container types while retaining laboratory-specific limits within the corresponding Function-Skill and shared constant rather than generalizing beyond documented capabilities.The container set includes vessels, holders, plates, and related laboratory objects supported by the current common runtime.Source: Supplementary Note 2. Primitive… · p. 12

Supplementary Note 3. Mathematical semantics of workflow composition · Sequential composition · Bounded loop

Supplementary Note 3 formalizes workflow composition as control-flow operators that preserve primitive-operation contracts. Sequential composition enforces intermediate-state validity, while bounded loops compose repeated bodies and terminate normally or at an upper bound.

Supplementary Note 3. Mathematical semantics of workflow composition

  • The five control-flow operators organize primitive transitions without changing their individual contracts.The mathematical definitions are given in Equations (2)–(14), with symbols defined in Supplementary Table S1.Source: Supplementary Note 3. Mathematical… · p. 14

Sequential composition

  • Sequential execution proceeds from right to left, requiring every intermediate state to satisfy the next operation’s precondition and domain.The formal construction indexes operations and characterizes states satisfying each operation’s precondition.Source: Sequential composition · p. 14
  • Sequential-composition notation is completed by definitions provided in Supplementary Table S1.Source: Sequential composition · p. 14

Bounded loop

  • A bounded loop is modeled by repeatedly composing its complete body, beginning with an identity mapping for zero executions.The loop body spans a designated range of operations, and the loop-entry state is used to define subsequent states.Source: Bounded loop · p. 14
  • Loop continuation is determined by a predicate evaluated after each completed body execution, distinguishing another iteration from normal exit.The resulting iteration count selects the first normal-exit state, or the upper bound when necessary.Source: Bounded loop · p. 14
  • The iteration count is formally defined over normal-exit states while including the maximum permitted count.Source: Bounded loop · p. 14
  • Reaching the upper bound while the continuation predicate remains true produces a non-Source: Bounded loop · p. 14

Conditional branch

The conditional branch operator selects the unique active branch using mutually exclusive, collectively exhaustive guards. Parallel branches operate on projected local state and synchronize through deterministic merging that excludes conflicting updates.

Conditional branch

  • Mutually exclusive and collectively exhaustive guards ensure that each input selects one unique active branch.The active branch is identified by the unique index whose guard evaluates as true.Source: Conditional branch · pp. 14–15
  • Parallel execution projects the global state onto branch-local objects and resources, then merges branch outputs at a synchronization point.This supports parallel operations on shared read-only state or distinct subsamples before joining.Source: Conditional branch · p. 15
  • Cross-branch write–read and write–write conflicts are excluded, while overlapping branch outputs must agree on shared state before deterministic merging.The constraints permit shared read-only state but prevent conflicting cross-branch updates.Source: Conditional branch · p. 15

Protected atomic interval

A protected atomic interval defines a contiguous, non-interleavable execution block whose operations occupy consecutive positions in the global schedule. No operation outside the block may be scheduled between its endpoints.

Definition

  • A protected interval A spans a specified operation range from !* through !+.The interval is defined for indices satisfying 1≤a≤b≤n.Source: Protected atomic interval · p. 15

Schedule placement

  • The operations in c occupy consecutive positions in the global execution schedule.Their positions are defined using the unique schedule location d(!!), with offsets covering the interval.Source: Protected atomic interval · pp. 15–16

Non-interleaving constraint

  • No operation outside c may be scheduled within the interval bounded by its endpoints.This establishes c as a protected, non-interleavable execution construct.Source: Protected atomic interval · p. 16

Supplementary Note 4. Nested workflow algebra and serialization

The nested workflow algebra represents complex laboratory programs as hierarchical compositions of sequences, loops, branches, parallel regions, and protected intervals. Serialization preserves this structure while recording topology and workstation-specific execution metadata in canonical JSON representations.

Supplementary Note 4. Nested workflow algebra and serialization

  • The executable representation preserves nested workflow hierarchy as an abstract syntax tree, including ordered primitives, bounded loops, fork–join regions, conditionals, and protected intervals.The expanded workflow synchronizes parallel branch outputs before evaluating the outer stopping condition.Source: Supplementary Note 4. Nested workflow… · p. 17
  • Physical operations serialize as namespace function calls, while parallel_execution, atomic_lock, Python conditionals, and bounded while or for loops retain their nested structure.The converter recursively serializes these constructs into JSON without flattening them.Source: Supplementary Note 4. Nested workflow… · p. 17
  • The converter produces a canonical structural string using SEQ, PAR, ATOMIC, IF, WHILE, and FOR, with operations indexed as f_i and topology separated from chemical thresholds.This representation captures workflow structure rather than chemical threshold values.Source: Supplementary Note 4. Nested workflow… · p. 17
  • The JSON records plan metadata, ordered steps, workstation and operation details, parameters, graph paths, switch mappings, and workstation_eng_name for deterministic interface routing.Recorded fields include the plan name, variables, workstation names, operation names, and parameters.Source: Supplementary Note 4. Nested workflow… · p. 17

Supplementary Note 5. Capability acquisition and Function-Skill admission

The capability-acquisition pipeline turns structured workstation descriptions or manually authored Skills into assessed, typed Function-Skill interfaces with simulator implementations. Workflows undergo analysis, simulation, review, and configured checks before downstream dispatch.

Capability layer

  • The release defines 49 workstation specifications and 63 namespaced Function-Skill functions, including 45 physical workstations and four virtual control-flow modules.The virtual modules provide parallel, conditional, loop, and protected-interval constructs.Source: Supplementary Note 5. Capability… · p. 18

Capability acquisition

  • Capability acquisition uses workstation information covering identities, operations, parameters, constraints, state transitions, returns, and file parameters.Natural-language Skills are assessed on a configurable 100-point scale: six required checks contribute 60 points, admission requires at least 60, and nine optional checks contribute 40 points.Source: Supplementary Note 5. Capability… · p. 18

Function-Skill conversion

  • Admitted Skills are converted into typed Function-Skill interfaces, shared runtime code, and simulator code implementing declared checks and state changes.Each interface function includes an eight-part docstring covering Summary, Preconditions, Cautions, Args, Constraints, State Changes, Returns, and Example.Source: Supplementary Note 5. Capability… · p. 18

Workflow admission

  • Generated workflows become dispatch candidates only after recipe analysis, simulation, review, configured checks, and diagnostic-driven regeneration when necessary.The supplied materials include the Skill library, shared runtime, simulator, and conversion or assessment sources, but provide no version tag or commit identifier.Source: Supplementary Note 5. Capability… · p. 18

Supplementary Note 6. Static analysis and recipe optimization

The recipe optimizer statically analyzes generated Python recipes, enforces a bounded language, and progressively applies validated normalization and optimization. Static acceptance complements, rather than replaces, stateful simulation and scientific review.

Static analysis

  • The security gate parses recipes into abstract syntax trees, restricts syntax and imports, blocks unsafe execution and access functions, and validates calls against the Function-Skill library.Accepted trees are serialized into canonical JSON, establishing conformance to the recipe language and workstation-call inventory.Source: Supplementary Note 6. Static analysis… · p. 19

Recipe optimization

  • The optimizer defines cumulative levels O0–O4, from security gating through admission, flow analysis, semantics-preserving simplification, conditional-output disabling, and compatible-call merging.The supplied configuration defaults to O0, enables O0–O2, disables O3–O4, and rechecks every transformed tree.Source: Supplementary Note 6. Static analysis… · p. 19

Validation and scope

  • O2 structural analysis passed in all four archived case-validation reports, with no O3 or O4 transformation applied.Static acceptance does not replace simulator stateful checks or scientific review of whether the workflow addresses its stated intent.Source: Supplementary Note 6. Static analysis… · p. 19

Supplementary Note 7. Stateful simulation and diagnostic-guided regeneration

Stateful simulation validates operations against executable laboratory state before committing transitions, aggregates diagnostics, and accepts workflows only when MUST constraints pass. The framework supports diagnostic-guided regeneration while preserving control-flow structure, but Fig. 2c presents a schematic rather than an archived regeneration trace.

Stateful validation

  • The simulator validates each operation against executable state and commits its transition only when all MUST constraints pass.Failed calls do not partially modify simulation state; downstream compatibility checks continue and produce diagnostics.Source: Supplementary Note 7. Stateful… · p. 20

Diagnostics

  • Validation returns separate MUST and SHOULD outcomes, with structured ErrorEntry diagnostics covering operation context, expected-versus-actual values, remediation, and failure categories.Categories include volume, container, status, parameter, temperature, time, speed, pressure, file, material, sample-state, workflow, and general simulation failures; Supplementary Table S8 defines the reporting schema.Source: Supplementary Note 7. Stateful… · p. 20

Execution and regeneration

  • The runner resets simulation state, executes generated recipes, separates errors from warnings, and accepts workflows only when the MUST-error list is empty.Virtual control-flow contexts record protected and parallel-block entry and exit events, while JSON conversion preserves nested topology for downstream adapters.Source: Supplementary Note 7. Stateful… · p. 20

Scope and limitation

  • Fig. 2c illustrates the validate–diagnose–regenerate pattern schematically, not through a case-specific archived regeneration trace.The section cross-references Fig. 2c, Supplementary Table S8, Supplementary Figs. S5 and S6, Supplementary Data 4, and Additional File 1.Source: Supplementary Note 7. Stateful… · p. 20

Supplementary Note 8. Fe coordination environment and alkaline OER workflow

The Fe coordination environment case specifies a matched alkaline OER workflow comparing Fe incorporation routes and validates its executable representation through structural checks and stateful simulation. The evidence establishes workflow admissibility, not coordination assignments or measured OER performance.

Fe coordination environment and alkaline OER workflow

  • The workflow compares Fe-free, co-precipitated, post-impregnated, citrate-complexed, and EDTA-complexed Fe routes under matched loading and electrochemical conditions.It includes precursor addition, mixing, drying/redispersion, XRD/infrared characterization, and alkaline OER testing.Source: Supplementary Note 8. Fe coordination… · p. 21
  • Simulation passed for the 27-step workflow with zero MUST errors and zero SHOULD warnings, while O2 structural analysis also passed.The canonical workflow is linear, uses 11 workstations, and encodes no parallel branch or bounded loop.Source: Supplementary Note 8. Fe coordination… · p. 21
  • The case manifest specifies three independent batches, matched synthesis/OER aliquots, and external Fe-coordination confirmation using XANES/EXAFS, XPS, ICP-OES, and optional 57Fe Mossbauer spectroscopy.These measurements are specified as planned confirmation rather than reported outcomes.Source: Supplementary Note 8. Fe coordination… · p. 21
  • The reported evidence is limited to automated semantic review, structural checks, and stateful simulation; physical execution data are not included.Accordingly, the workflow establishes capability-relative structure and simulation admissibility but does not establish coordination assignment or measured OER performance.Source: Supplementary Note 8. Fe coordination… · p. 21

Supplementary Note 12. Reproducibility and release package

This section describes the reproducibility and release package, including its code, Function-Skill libraries, workflow materials, documentation, configuration, logs, validation evidence, and software/model manifests. It also identifies incomplete metadata and access provisions, missing dependency locking, internal provenance limitations, and the need to remove sensitive or temporary material before release.

Reproduction requirements

  • Reproduction requires frozen software and Function-Skill releases plus exact workflow artifacts, including prompts, recipes, AST/JSON outputs, semantic-review reports, and simulation logs.The intended release also includes the recipe optimizer, simulator runner and implementation, common runtime, converters, quality assessor, configuration files, dependency specification, and documentation.Source: Supplementary Note 12. Reproducibility… · p. 25

Release contents

  • The supplied package includes a source-code archive, a 49-workstation Function-Skill library, a four-case workflow archive, and release-page text, with the three local archives catalogued in Supplementary Table S12.The local source archive contains the optimizer, simulator, converter, runtime, and configuration files.Source: Supplementary Note 12. Reproducibility… · p. 25

Reproducibility gaps

  • The supplied package omits a commit identifier, dependency lockfile, final non-sensitive model record, exact provider/model settings, decoding parameters, random seeds, and a deterministic reproduction statement.These fields remain release metadata rather than values inferred from the available case dialogues and archives.Source: Supplementary Note 12. Reproducibility… · p. 25

Release conditions

  • Before public or reviewer release, the source archive must remove credential-bearing configuration, internal object-storage URLs, temporary files, and local paths; AF-04 is not a persistent public link.Additional File 4 is an author-supplied internal release-page record rather than a verified persistent public or reviewer-access repository.Source: Supplementary Note 12. Reproducibility… · p. 25

Reproduction records

Manifest

Limitations

Release package

  • The package releases source-code and Function-Skill archives alongside Extended Data Fig. 1 workflow and case archives.The listed artifacts include AF-01 Source-code archive.zip, AF-02 Function-Skill library.zip, and AF-03 Extended Data Fig. 1 workflow archive.zip, plus an Extended Data Fig. 1 case archive.Source: Supplementary Note 12. Reproducibility… · p. 41

Supplementary Figures

The supplementary figures document stateful workflow execution, operator admissibility, capability and Skill representations, validation mechanisms, and four application workflows. Together with the supplementary data, they provide supporting implementation, simulation, and reproducibility records.

Stateful workflow

  • Supplementary Fig. S1 formalizes a stateful synthesis–characterization workflow with a protected sequence, pH-dependent wash loop, parallel UV-vis/XRD analysis, and research-object states S1–S14.Source: Figure S1 · p. 42, Supplementary Figures · p. 42

Operator admissibility

  • Supplementary Fig. S2 illustrates admissibility checks for sequence, loop, conditional, parallel, and protected-interval operators, rejecting violations before state transitions commit.Each operator has a mandatory structural invariant, with localized diagnostics for rejected execution patterns.Source: Figure S2 · p. 43, Supplementary Figures · p. 43

Capability inventory

  • Supplementary Fig. S3 organizes 49 workstation specifications into synthesis, reaction and testing, characterization, and virtual control-flow categories, alongside a capability taxonomy.The taxonomy spans material and container management, sample handling, processing, separation, reaction, and characterization.Source: Figure S3 · p. 44, Supplementary Figures · p. 44

Application workflows

  • Supplementary Figs. S7–S10 present four generated and simulated workflows covering Fe coordination and alkaline OER, LDH–HMF oxidation, furfural hydrogenation, and adaptive ZnO spectroscopy.These workflows include matched route comparisons, integrated characterization, closed-loop GC optimization, and bounded UV–Vis dilution-and-remeasurement.Source: Figure S3 · p. 44, Figure S7 · p. 48, Figure S8 · p. 49

Skill and simulation validation

  • Supplementary Figs. S4–S6 define Skill admission, conservative recipe analysis, and validate-then-commit simulation with structured diagnostics and non-blocking SHOULD warnings.The Skill rubric totals 100 points; accepted recipes proceed to simulation, while failed MUST constraints preserve the current state without mutation.Source: Figure S4 · p. 45, Figure S5 · p. 46, Figure S6 · p. 47

Supplementary records

  • The SI guide links Notes 1–12, Tables S1–S12, Figs. S1–S10, capability and operation registries, formal workflow records, evidence files, and reproducibility manifests.The listed archives include machine-readable inventories, canonical JSON workflows, validation reports, source code, the frozen 49-workstation library, and checksums.Source: Supplementary Figures · p. 52
Loading 2609.03621v1…