# Fileset

[d6dd00301j.pdf](https://mdr.nims.go.jp/filesets/19394299-dbea-4317-bc99-41a480b3b5e4/download)

## Creator

[Yuuya Nagata](https://orcid.org/0000-0001-5926-5845), Kojiro Machi, Seiji Akiyama, [Masaharu Yoshioka](https://orcid.org/0000-0002-2096-1218)

## Rights

[Creative Commons BY Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)

## Other metadata

[A software framework for translating literature-derived χDL procedures into execution-format programs on the Chemspeed automation platform](https://mdr.nims.go.jp/datasets/3093d8b0-a06a-4db0-aeff-d25e6020b851)

## Fulltext

DigitalDiscoveryPAPERPublished on 17 August 2026Licensed under CC-BY 4.0A software frameaAutonomous Polymer Design and DiscoveryScience, 1-2-1 Sengen, Tsukuba, Ibaraki 30nims.go.jpbGraduate School of Information Science andNishi 9, Kita-ku, Sapporo, Hokkaido 060-08cAdvanced General Intelligence for SciencRIKEN, Wako, Saitama, JapandInstitute for Chemical Reaction Design aUniversity, Kita 21 Nishi 10, Kita-ku, SappoeFaculty of Information Science and TechnolKita-ku, Sapporo, Hokkaido 060-0814, JapaCite this: DOI: 10.1039/d6dd00301jReceived 22nd May 2026Accepted 14th August 2026DOI: 10.1039/d6dd00301jrsc.li/digitaldiscovery© 2026 The Author(s). Published bwork for translating literature-derived cDL procedures into execution-formatprograms on the Chemspeed automation platformYuuya Nagata, *a Kojiro Machi,b Seiji Akiyamac and Masaharu Yoshioka bdexdl2chemspeed is a software framework that translates literature-derived cDL procedures into execution-format programs for the Chemspeed automation platform. The workflow reads cDL files, uses an LLM-assisted mapping stage to generate an intermediate Chemspeed command CSV, and appliesa deterministic downstream converter for CSV quoting, zone renaming, unit normalisation, reflux-temperature substitution, global loading scaling, and reagent-position table generation. A deterministicXML-parsing reference converter was implemented to test the cDL-to-CSV mapping independently ofthe LLM. For four Organic Syntheses procedures containing 47 cDL actions, the reference converter andLLM-assisted route produced byte-for-byte identical intermediate and final CSV files after downstreamconversion. The reference route also writes row-level provenance sidecars that link each generated rowto the source cDL step, source parameter, normalized value, conversion rule, software version, and filehashes, while preserving the Chemspeed execution CSV schema. An expert fidelity audit assigned 44actions as correctly expanded and 3 as intentionally omitted because the current Chemspeed executionformat has no corresponding field, with no action-level mistranslations. Ten independent runs withremote and local language models gave byte-for-byte identical final execution files after deterministicpost-processing. The generated program for the benzylation of 3,4-dimethoxyphenol was executed ona Chemspeed SWING workstation without manual CSV correction, affording 4-benzyloxy-1,2-dimethoxybenzene in 84.4% isolated yield at 2.65 mmol scale. The framework provides an auditablebridge between structured synthesis procedures and commercial laboratory automation hardware.1 IntroductionThe digitization of synthetic chemistry is increasingly impor-tant because organic synthesis procedures are still communi-catedmainly as prose in journal articles and patents. Such proseis informative for trained chemists, but it is intrinsically diffi-cult to search, normalize, validate, and execute on automatedplatforms. This limitation is particularly acute for materialsscience, where discovery and optimization of functional mate-rials such as photocatalysts, organic semiconductors, andbattery electrolytes depend on rapid screening of molecular andformulation spaces. Recent reviews have established self-Group, National Institute for Materials5-0047, Japan. E-mail: NAGATA.Yuuya@Technology, Hokkaido University, Kita 1414, Japane Program (AGIS), TRIP Headquarters,nd Discovery (WPI-ICReDD), Hokkaidoro, Hokkaido 001-0021, Japanogy, Hokkaido University, Kita 14 Nishi 9,ny the Royal Society of Chemistrydriving laboratories and materials acceleration platforms asa research paradigm in which automated experimentation, datainfrastructure, and algorithmic decision-making are integratedinto a closed experimental loop.1–8 Landmark demonstrationssuch as Ada, which is a self-driving laboratory for thin-lmmaterials optimization, and the mobile robotic chemist forautonomous photocatalyst discovery illustrate both the promiseof this paradigm and the dependence of its success on sowarethat couples high-level experimental intent to low-level hard-ware execution.9,10Within this broader movement, the Aspuru-Guzik group hasplayed a central conceptual role. ChemOS provided an orches-tration layer for autonomous experimentation and claried howplanning, execution, and analysis modules can be coupledwithin a unied soware stack.11 Subsequent work from thesame community and related collaborators further dened thescope, opportunities, and practical challenges of self-drivinglaboratories, including questions of interoperability,autonomy level, cost, and laboratory accessibility.1,3,5,7 Thesestudies established a systems-level perspective, but they alsomake clear that overall autonomy depends critically on thereliability of the procedural representation that connectshuman-readable chemistry with machine execution.3,5Digital Discoveryhttp://crossmark.crossref.org/dialog/?doi=10.1039/d6dd00301j&domain=pdf&date_stamp=2026-08-18http://orcid.org/0000-0001-5926-5845http://orcid.org/0000-0002-2096-1218https://creativecommons.org/licenses/by/4.0/Digital Discovery PaperIn parallel with these developments, the Cronin groupintroduced a complementary line of research based on a formalchemical programming language and modular hardware. TheChemputer work showed that synthetic procedures can bedecomposed into abstract operations and executed reproduc-ibly in a modular robotic environment.12 This abstraction wassubsequently extended into a universal framework for digitizingand automatically executing the chemical synthesis literature,in which cDL was proposed as a machine-readable andhardware-agnostic representation of synthetic protocols.13 Morerecent studies demonstrated cross-platform repeatability andexpanded programmability through reusable higher-levelconstructs such as reaction blueprints and logical controlow.14,15 Collectively, these studies indicate that cDL can serveas a portable intermediate language between textual chemistryknowledge and robotic execution.The conversion of textual procedures into structured proce-dure languages has also advanced substantially in recent years.Vaucher and coworkers at IBM Research trained a transformer-based sequence-to-sequence model that converts Englishexperimental procedures into structured action sequences anddeployed it on the cloud-based RXN for Chemistry platform.16We previously developed OSPAR, which is a corpus for extrac-tion of organic synthesis procedures with argument roles, torepresent actions together with semantically related entitiesand parameters in an interpretable annotation framework.17 Wethen proposed a framework for reviewing the results of auto-mated conversion of structured organic synthesis proceduresfrom the literature, in which annotated text and multiplecandidate structured outputs support human correction andvalidation.18 These studies addressed an upstream problem,namely how natural-language procedures can be mapped tostructured procedural descriptions while preserving semantictransparency for expert review. This upstream perspective hasrecently been strengthened by work from the Aspuru-Guzikgroup and collaborators on large language models for chem-istry robotics. In particular, CLAIRify showed that natural-language instructions can be translated into robot-executableplans with verier-assisted generation, using cDL asa domain-specic language in a broader task-and-motion-planning framework.19Nevertheless, an intermediate language is only useful inpractice when robust translation layers are available for specicexperimental infrastructures. Many materials laboratoriesoperate commercial automation systems rather than Chem-puter architectures or fully bespoke robotic platforms. In suchsettings, the practical bottleneck oen lies not in the conceptualvalidity of cDL but in the absence of reliable soware thatconverts cDL procedures into the command structures, reagenttables, zone assignments, and hardware conventions requiredby a given platform.5,6,20 This issue is particularly important forChemspeed systems, which are among the most widelydeployed commercial platforms for parallel organic synthesis,formulation, and materials screening. The mismatch inabstraction level between cDL, which is a chemically motivatedaction language, and the Chemspeed program format, which isDigital Discoverya zone-oriented command table, is the gap that the presentwork addresses.The present study focuses on the deployment layer betweenstructured procedure representation and commercial hardwareexecution. Rather than generating cDL from text, we assumethat an cDL procedure is already available, either by manualauthoring or by automated extraction and review.16–18 We thenconvert that cDL procedure into a Chemspeed-orientedprogram with platform-specic normalization and parser-robust formatting. The contribution of this paper thereforelies between literature digitization and robotic execution ona commercial materials-synthesis platform. Fig. 1 places thiscontribution in the overall workow from literature prose tohardware execution; the corresponding soware architecture isdetailed later in Fig. 2.We deliberately adopt an LLM-assisted mapping stage forthis deployment layer, rather than a purely rule-based XML-to-CSV translator. This choice is motivated by three consider-ations. First, the broader pipeline that this work is designed toserve begins from natural-language experimental procedures.CLAIRify demonstrated that natural-language instructions canbe translated into cDL through verier-assisted LLM genera-tion,19 and our own review-oriented framework for automatedconversion of organic synthesis procedures likewise relies onLLM-based structured-output generation as its core compo-nent.18 Because the intended end-to-end workow is naturallanguage/ cDL/ Chemspeed, it is architecturally consistentto retain an LLM-based interface at the downstream cDL /Chemspeed step as well, so that the whole chain can shareprompt-engineering infrastructure, model endpoints, andoperational monitoring. Second, cDL itself is a living speci-cation whose action vocabulary is expected to grow as additionalhardware capabilities are incorporated. A prompt-drivenmapping stage that consumes a textual format descriptioncan accommodate new or rarely encountered cDL elementswithout re-implementing a deterministic parser, whereasa hand-coded rule table must be extended for every newelement. Third, LLMs naturally absorb benign surface variationin the cDL input, such as synonymous parameter names, minorwhitespace or casing differences, and non-canonical reagentlabels, which would otherwise require extensive defensivecoding. We combine this exibility with deterministic rule-based post-processing (Stage 3), which yielded byte-for-byteidentical nal machine-readable protocols in the ten-runbenchmark described in Section 3.3. We emphasise a prac-tical consequence of this design for prospective users: themapping stage requires no model ne-tuning and no curatedfew-shot examples, because its entire behaviour is speciedthrough plain-text format descriptions. Deploying the frame-work on new or proprietary cDL procedures therefore reduces toediting a text le rather than to training or maintaininga machine-learning model, which substantially lowers thebarrier to entry for experimental laboratories that do not employdedicated machine-learning engineers.To test whether the cDL / intermediate CSV step in isola-tion really requires an LLM, we additionally implementeda purely deterministic rule-based converter,© 2026 The Author(s). Published by the Royal Society of ChemistryFig. 1 Conceptual roadmap of the overall workflow addressed by this study. Published synthesis procedures written as prose are first convertedinto the machine-readable cDL representation, either by manual authoring or by automated extraction with expert review (prior work: trans-former-based action extraction,16 OSPAR,17 the review-oriented conversion framework,18 and CLAIRify19). The software reported here(xdl2chemspeed, red frame) translates the cDL procedure into an execution-format program: an LLM-assisted mapping stage produces aninspectable intermediate command CSV, and a deterministic converter produces the final workstation-oriented CSV and reagent-zone tabletogether with row-level provenance sidecars. After an operator audit of the generated file, the program is dispatched row by row to theChemspeed SWING workstation.Fig. 2 Software architecture of the xdl2chemspeed workflow (see Fig. 1 for the corresponding high-level conceptual roadmap). Blue boxesdenote data artifacts, orange boxes denote processing stages, green boxes denote hardware execution, and dashed arrows denote optionalinputs. The figure depicts the user-facing conversion and hardware-dispatch pathway from a cDL input file through LLM-assisted mapping,deterministic ChemspeedSystemConverter processing, generation of the converted execution-format CSV and chemical-zone table, androw-by-row dispatch to the Chemspeed SWING workstation through xdl2chemspeed_executar.app. The LLM-assisted mapping stageconsumes the cDL procedure together with static format descriptions, and either the OpenAI API or a local Ollama endpoint can be selected atthe command line. The deterministic converter performs heuristic global scaling against a 5.0 mL-equivalent maximum reactor load, sequentialzone renaming, reflux-temperature substitution against a solvent boiling-point table, unit normalisation of mass, volume, and time fields, andfinal-output provenance propagation. Row-level provenance sidecars are generated as companion audit artifacts during the deterministicreference and downstream-conversion steps. They are intentionally not loaded by the Chemspeed application and are therefore describedseparately in Table 3 and in the SI.© 2026 The Author(s). Published by the Royal Society of Chemistry Digital DiscoveryPaper Digital DiscoveryDigital Discovery Paperxdl2chemspeed_rulebased.py, that parses the cDL inputwith a standard XML parser and applies the same format-description rules used in the LLM prompt in a dictionary-based dispatcher. The rule-based converter reproduces thesame intermediate CSV schema: one-to-one tag mapping ofAdd, StartStir, Stir, StopStir, HeatChill, HeatCh-illToTemp, StartHeatChill, StopHeatChill, Wait,Purge, and EvacuateAndRell; canonical Stir/Wait/StirOff triplets for timed Stir steps; normalization of the cDLHardware element with id=“reactor” to reactor1; thefull-transfer total-mixture recovery rule for quantity-omittedTransfer from an unsplit mixture vessel; and the fallbackcomponent-level recovery rule when the total-mixture rule is notjustied. On the four-case benchmark of Section 5, the inter-mediate CSVs produced by the rule-based converter are byte-for-byte identical to those produced by the LLM pipeline, andconsequently the nal *_converted.csv les obtained byfeeding either intermediate through the same Chem-speedSystemConverter.py post-processor are also byte-for-byte identical for all four cases. This cross-implementationequivalence indicates that the Chemspeed format descriptionas currently specied is semantically complete for theseprocedures and that the LLM stage does not introduce unre-coverable ambiguity relative to a deterministic parser. The rule-based converter is therefore not proposed as a replacement forthe LLM stage; rather, it serves as a deterministic referenceimplementation that cross-validates the LLM output on thebenchmark cases and claries the role of the LLM in thebroader pipeline. The rule-based route also writes a companionprovenance le, <stem>_provenance.csv, in which eachintermediate row is linked to the source cDL le, source-stepindex, source-step identier, source-step type, source param-eter, original value, normalized value, deterministic conversionrule, soware component, and SHA-256 le hashes. When theupstream step is already natural-language / cDL by anLLM,18,19 retaining an LLM at the cDL/ Chemspeed step keepsthe whole pipeline homogeneous in its prompt-engineeringinfrastructure, model endpoints, and operational monitoring,and allows themapping to adapt to future extensions of the cDLaction vocabulary through prompt-level updates alone; the rule-based converter would instead require a source-code change forevery new tag. For deployments where only the cDL / Chem-speed step is exercised, for example when cDL les are auth-ored or reviewed manually, the rule-based converter offersa deterministic, dependency-free alternative with the same naloutput and with deterministic source-step provenance. Weacknowledge that the LLM route does not remove the mainte-nance burden entirely: any update of the cDL specicationrequires re-validation of the mapping layer regardless ofwhether that layer is implemented as a prompt or as code, andgenuinely new command types additionally require extendingthe downstream execution interpreter. The practical distinctionlies in where routine extensions land. Many cDL extensionsdecompose into the existing Chemspeed command vocabulary(for example, a new action tag whose semantics expand intoexisting TrsV, Wait, and HeatCool rows), and for these theprompt-based route requires only a format-description edit,Digital Discoverywhereas even a well-designed extensible deterministicdispatcher still requires source-code changes, review, and re-release. In addition, whether the LLM route tolerates surfacevariation of the input that a strict parser rejects is an empiricalquestion, which we examine directly in Section 3.4; the bench-mark reported there shows complementary failure surfaces forthe two routes under surface perturbation and identiesprompt-level updates that extend the tolerance of the LLM routefurther. Because the deterministic converter is distributedalongside the LLM route, deployments that prefer a fullydeterministic translation path can adopt it directly; the tworoutes are complementary rather than competing.2 Concept and scope of the softwareBecause the concrete implementation targets a ChemspeedSWINGworkstation, it is useful to state at the outset which partsof the framework are generalizable and which are platform-specic. Generalizable components include the separation ofthe workow into an inspectable intermediate representationand a nal workstation-oriented representation; the prompt-driven mapping stage, whose behaviour is congured entirelyby a plain-text format description; the deterministic post-processing stage that absorbs the residual stochasticity of theLLM output; the row-level provenance sidecar schema; and themethodology of cross-validating the LLM route against a deter-ministic reference converter. Platform-specic componentsinclude the concrete command vocabulary and CSV schema ofTable 1, the sequential zone-naming convention, the loading-scale heuristic and its parameters, the reux-substitutiontable, and the xdl2chemspeed_executar.app dispatchlayer. Porting the framework to a different automation platformtherefore amounts to replacing the format description and theemission rules of the downstream converter, while the archi-tecture, prompting strategy, provenance schema, and validationmethodology carry over unchanged. Where helpful, the stagedescriptions below open with an indication of which side of thisdivision they belong to.2.1 Design principlesThe soware, hereaer referred to as xdl2chemspeed, isdesigned to accept cDL les that represent organic synthesisprocedures and to transform them into Chemspeed-orientedcommand les. The present implementation focuses on theexecution layer rather than on the extraction of procedures fromraw literature text. The soware therefore builds upon thestructured representations established in our earlier work17,18and on existing upstream extraction pipelines.16,19Five design principles guide the current architecture. First,the workow is separated into an intermediate representationand a nal workstation-oriented representation. This separa-tion improves maintainability and makes the mapping fromcDL actions to Chemspeed operations inspectable. Second,downstream formatting is isolated in a dedicated converterscript. This design permits local changes in naming, scaling,and reux handling without modication of the upstream© 2026 The Author(s). Published by the Royal Society of ChemistryTable 1 Chemspeed control-command set used by the present pipeline. Each row of the Chemspeed execution-format CSV is one of thesecommands. Items in square brackets are optional fields permitted by the format description; the exact CSV-arity and trailing-commaconventions supplied to the LLM are documented in the SI. The VacRefill entry is included for completeness because it can appear in theintermediate CSV as the translation target of cDL EvacuateAndRefill and Purge actions, but in the present deployment it is intentionallyomitted by the downstream converter for the deck-level inertisation reason discussed in Sections 2.1 and 4.5Command Schema (CSV elds) Role on the Chemspeed workstationTrsV TrsV, SourceZone, DestinZone,Volume, [Flowrate]Volumetric liquid transfer from SourceZone to DestinZone. Volume carries an explicitunit (mL or mL) in the intermediate CSV and a numerical mL-equivalent value in theconverted CSV aer global loading scalingTrsG TrsG, SourceZone, DestinZone,WeightGravimetric solid transfer. Weight carries an explicit unit (g or mg) in the intermediateCSV and a numerical g-equivalent value in the converted CSV aer global loadingscalingStir Stir, Zone, [AngularSpeed] Start stirring in the specied zone. The optional AngularSpeed eld carries an explicitrate (e.g. 200 rpm) when provided by the source cDL; otherwise it is le blank and theworkstation applies its default rate. A timed cDL Stir step is expanded into thecanonical triplet Stir, Zone/Wait, T/StirOff, ZoneStirOff StirOff, Zone Stop stirring in the specied zone. Emitted both as the closing line of the canonicalStir/Wait/StirOff triplet for a timed cDL Stir step and as the translation of an explicitcDL StopStir actionHeatCool HeatCool, Zone, Temperature Set the temperature setpoint of the specied zone (used for both heating and cooling).Temperature carries an explicit unit (°C, K, or the special token reux) in theintermediate CSV and a numerical °C value in the converted CSV, with reux resolvedagainst the solvent boiling-point table during Stage 3 conversion. A terminal cDLStopHeatChill action is rendered as HeatCool, zone, 25.0000 to return the zone toambient temperatureWait Wait, Time Hold the current state of the workstation for the specied duration. Time carries anexplicit unit (s, min, or h) in the intermediate CSV and is normalised to minutes in theconverted CSVVacRell VacRell, Gas, [Iteration] Replacement (evacuate/rell) cycle for a zone, with the specied inert gas (one of Ar,N2, CO2). Used as the translation target of cDL EvacuateAndRell and purge actions inthe intermediate CSV. Intentionally omitted (schema dropout, Section 5) by thedownstream converter in the present deployment (see Sections 2.1 and 4.5)END END Terminate the program. Each Chemspeed execution-format CSV ends with a singleEND rowPaper Digital Discoverymapping prompt. Third, the pipeline includes an explicitprotection step for comma-containing reagent names. In thecurrent implementation this protection is achieved by selectivequotation of only the second CSV eld in TrsG (solid transfer)and TrsV (liquid transfer) rows; Table 1 summarises the fullChemspeed control-command set used by the pipeline. Thisdesign preserves reagent labels such as 3,4-di-methoxyphenol without breaking CSV column structure.Fourth, row-level provenance is written as sidecar CSV lesrather than as additional columns in the execution CSV. Thisdesign preserves compatibility with the Chemspeed applicationwhile retaining an auditable transformation trace for eachgenerated row. For a chemistry reader, these sidecar les playthe same role as a laboratory-notebook cross-reference: for everyrow that the robot will execute, they answer the questions ofwhich literature-derived step produced it and which ruleproduced its numerical value. The SHA-256 le hashes recordedin the sidecars in turn guarantee that the le being audited isexactly the le that was, or will be, executed, so that a prove-nance record cannot silently refer to an outdated or edited copyof the program. Fih, the cDL/ intermediate CSV mapping isdelegated to an LLM rather than to a hand-coded deterministictranslator in the primary route. This decision keeps themapping layer homogeneous with the upstream natural-© 2026 The Author(s). Published by the Royal Society of Chemistrylanguage / cDL stage used in CLAIRify19 and in our ownreview-oriented framework,18 and it allows the mapping toabsorb extensions of the cDL vocabulary or unfamiliar actionelements simply by updating the accompanying formatdescription, without re-implementing a parser and without anymodel ne-tuning or curated few-shot examples. The residualformatting variability of the LLM stage is then removed for thebenchmark cases by deterministic Stage 3 post-processing, asquantied in Section 3.3.The present implementation also has explicit limits that areimportant for interpretation. The deterministic rule-basedroute provides source-step provenance for the benchmarkcases, and the downstream converter propagates this prove-nance into nal-output audit les. The LLM-assisted routewrites generated-rowmetadata but does not claim deterministicsource-step attribution, because the prompt-based output is notyet coupled to a verier that enforces a one-to-one relationbetween input actions and output rows. For this reason, LLM-derived intermediate les should be treated as reviewable arti-facts before execution, even though the rule-based cross-checkprovides deterministic provenance for the same benchmarkoutputs. In addition, the converter intentionally maps inert-gasexchange commands such as EvacuateAndRell to no-oprows because the target Chemspeed SWING workstation inDigital DiscoveryDigital Discovery Paperthis study performs an instrument-level inert-gas purge of theentire deck. Under the standard operating conditions used inour laboratory, nitrogen purging of the workstation enclosurereduces the ambient oxygen concentration inside the deck tobelow 100 ppm as measured by an in-line oxygen sensor, and wehave conrmed empirically that a range of oxygen-sensitiveorganometallic reactions, including palladium- and copper-catalysed cross-couplings, proceed without complication inthis atmosphere. Per-vial gas exchange is therefore redundantfor the enclosure used here. We emphasise, however, that this isa deployment-dependent design choice: operators usinga workstation without enclosure-level inertisation will need toprovide an alternative mapping rule that emits explicit per-vialgas-exchange rows into the converted CSV. Rows that areintentionally dropped in the current deployment are retained inthe nal provenance sidecar with status=-dropped_by_downstream_converter, so that schema-levelomissions remain visible during audit.2.2 Chemspeed program format and the translation gapA Chemspeed program is a tabular command le in which eachrow represents a hardware-level operation such as liquidtransfer, solid transfer, stirring, heating, waiting, or programtermination. Rows reference zones, reagents, and numericalparameters with units that are expected by the downstreamworkstation environment. cDL, in contrast, is an XML-basedaction language whose elements, such as Add, HeatChill,and Stir, refer to chemical actions rather than hardwareaddresses and whose parameters may use different textualconventions. Direct one-to-one mapping is therefore not guar-anteed in general. A single cDL HeatChill block may corre-spond to several Chemspeed rows or to a row plusaccompanying waiting logic, depending on the target format.The gap between chemically meaningful actions and hardware-oriented command rows motivates the use of an intermediaterepresentation that can be inspected before nal conversion.The complete set of Chemspeed control commands used by thepipeline, together with their CSV schemas and roles on theworkstation, is given in Table 1; subsequent sections refer tothese commands without re-introducing them.3 Software workflow3.1 Implementation detailsThis subsection describes the concrete realisation of the pipe-line: the two-stage architecture itself is platform-agnostic,whereas the le formats and conversion rules described hereare specic to the Chemspeed deployment. The developedpipeline consists of a series of conversion and normalizationsteps, whose soware architecture is summarized in Fig. 2(Fig. 1 gives the corresponding high-level conceptual roadmap).The main script, xdl2chemspeed.py, reads .xdl les froman input directory and writes generated artifacts to an outputdirectory. The script can connect either to the OpenAI API or toa local Ollama OpenAI-compatible endpoint. In the imple-mentation used for the reported experiments, the defaultDigital Discoveryremote model is gpt-4o-2024-05-13, and the default localmodel is gpt-oss-120b; the function-level structure of theclient construction, the endpoint selection, and the command-line interface are documented in the SI.The LLM prompt is assembled entirely as a user message.The prompt concatenates an cDL description le, a Chemspeedformat description le, the raw cDL procedure, and aninstruction that requires the model to write the generatedprogram between <OUTPUT> and </OUTPUT> tags. The currentscript does not introduce a separate system prompt, few-shotexamples, automated retries, or a verier model. Thesampling conguration is chosen so that the randomness of theLLM output is controlled solely through the temperatureparameter and so that the legitimate row-level token repetitionsof the target CSV schema are not penalised; the exact parametervalues, the rationale for each choice, and the model-dependenttoken-limit handling are documented in the SI. Aer inference,the script extracts the text between the output tags and removesblank lines.A dedicated post-processing step then reconstructs only thesecond CSV eld of TrsG and TrsV lines and encloses that eldin quotation marks (the corresponding function-level detailsare given in the SI). This step is central to the present studybecause naive comma splitting would otherwise corrupt reagentlabels that contain commas.The downstream converter, Chem-speedSystemConverter.py, reads the intermediate CSVwith a standard CSV parser (parser settings in the SI) andapplies a heuristic loading model. In the reviewed versionsupplied with this manuscript, liquid inputs are weighted bya xed density proxy of 0.80, solid inputs are weighted by a xeddensity proxy of 1.00, and the default target maximum zone loadproxy is 5.0 mL-equivalent. The resulting global scaling factor iscalculated from the largest aggregated zone-load proxy accord-ing to eqn (1). This calculation is a practical schedulingheuristic rather than a physical occupancy calculation. It isintended to generate a conservative rst-pass Chemspeedprogram for operator review, not to certify vial ll levels withouthuman inspection. For this reason, the execution-format CSVshould be reviewed by the operator before hardware deploy-ment, with particular attention to reaction concentration, mix-ing, headspace, solid swelling, and installation-specicdispensing limits. The converter generates sequential identi-ers such as zone-1 and solid-1. It also resolves the specialtoken reux by searching solvent_b-p_synonym_formula.csv aer removal of the reagent prexbefore the rst underscore. The synonym-expanded boiling-point table was constructed by taking a base list of commonorganic solvents and their boiling points (solvent_bp.csv,173 entries) and expanding each entry with synonyms, CASregistry numbers, and common trade or chemical-suppliernames retrieved from PubChem;21 the resulting lookup tablecontains approximately 16 000 rows and substantially improvesmatching robustness when reagent labels in the input cDL usenon-canonical names. If no matching solvent is found, theconverter returns a default value of 80.0000. The reviewedconverter also corrects latent unit-conversion errors for mg, uL,© 2026 The Author(s). Published by the Royal Society of ChemistryPaper Digital DiscoveryuL/min, and Hz; these units are not used in the archivedbenchmark CSV outputs, so the correction does not alter thefour converted CSV les reported in the manuscript. Whena companion intermediate provenance le is present, theconverter writes <stem>_converted_provenance.csv andpropagates source-step metadata, conversion-rule identiers,zone assignments, unit transformations, the global scalingfactor, the soware version, the chemical-zone table lename,and le hashes into the nal-output audit trail.3.2 Validation scopeThe present revision supports one literature-derived case studywith hardware execution and three additional literature-derivedprocedures for le-generation and delity benchmarking. Itdemonstrates parser-level robustness, transparent inspection ofintermediate outputs, output-layer reproducibility over tenindependent runs (Section 3.3), deterministic row-level prove-nance for the rule-based reference route, and end-to-end hard-ware execution on a Chemspeed SWING workstation for thebenzylation case. It does not yet provide hardware validation forall benchmark procedures, deterministic source-step attribu-tion for the LLM-assisted route, or blind multi-annotator step-delity scoring. Table 2 summarizes the current scope.The hardware execution result establishes that the auto-matically generated command le is operationally valid for thepresent case study. Translation behaviour across a smallbenchmark of additional literature-derived cDL procedures isTable 2 Validation scope in the present manuscriptItem Current statusSource procedures One hardware-executed literature-Okaya et al.,22 plus three additionSynthesesIntermediate generation Successful creation of an intermeworkowComma-containing labelhandlingSuccessful preservation of reagentsecond eld in TrsG and TrsV rowConverter behaviour Successful creation of v93p0063_cothe supplied case studyLLM output reproducibility Conrmed over ten independent rminor run-to-run variation; all tenbyte-for-byte identicalChemspeed hardwareexecutionValidated. The generated v93p006a Chemspeed SWING workstationdispensing unit, and a solid dispecorresponding to the quantities incolumn chromatography (15% EtOmg) with 1H NMR data consistentMulti-case delitybenchmarkPerformed on three additional liteaddition step,24 and Benkovics Stelevel delity analysis across the careported in Table 5 and classies 4omitted because the current Chemmistranslations observed; see SecRow-level provenancetracingImplemented for the deterministiIntermediate and nal sidecars munit normalization, zone assignmassisted route records generated-r© 2026 The Author(s). Published by the Royal Society of Chemistryreported in Section 5. Hardware execution of those additionalcases, verier-coupled source-step attribution for the LLM-assisted route, and blind multi-annotator scoring remainfuture work.3.3 Reproducibility of the LLM-assisted mapping stageTo evaluate the reproducibility of the LLM-based conversionpipeline, ten independent runs were performed using a xedsampling temperature of 0.2. The raw text returned by the LLMexhibited minor run-to-run variation, restricted to whitespacehandling and numerical formatting (for example, “8.32 g”versus “8.32 g”, or the presence of trailing commas) rather thanto the structural content, such as row count, command order, orreagent assignment. The deterministic second-eld quotingstep executed immediately aer the LLM call, and the subse-quent Stage 3 processing in Chem-speedSystemConverter.py (unit normalisation, globalscaling, zone renaming, and reux substitution, with roundingto four decimal places) absorbed these formatting differencescompletely. As a result, all ten nal *_converted.csv lesproduced at the end of Stage 3 were byte-for-byte identical. Thiscombination of low-temperature sampling and rule-based post-processing gave byte-for-byte identical nal machine-readableprotocols in the archived ten-run benchmark, even though theintermediate CSV remained slightly variable in formatting. Thesame ten-run reproducibility test was repeated using the localgpt-oss-120b model served through the Ollama OpenAI-derived cDL case study based on Step A of the Organic Syntheses article byal literature-derived cDL benchmark procedures drawn from Organicdiate CSV le from the cDL input using the uploaded prompt-basedlabels such as 3,4-dimethoxyphenol through selective quotation of thesnverted.csv and v93p0063_chem_table.csv from the intermediate CSV inuns at sampling temperature 0.2. Stage 2 intermediate outputs showednal CSVs produced by the deterministic Stage 3 post-processor were3_converted.csv was executed without manual modication onequipped with a temperature-controlled 8 mL vial rack, a liquidnsing unit. The reaction was performed at 2.65 mmol scale,the converted CSV aer global scaling. Aer purication by silica gelAc/85% n-hexane), the target product was isolated in 84.4% yield (546.12with the literature (see SI)rature-derived cDL procedures (Okamoto Step A,23 Di Maso Michael-p A25) drawn from Organic Syntheses. A retrospective expert-curated step-se study and these three additional cases (47 cDL actions in total) is4 actions as correctly expanded and 3 as schema dropouts (intentionallyspeed schema has no corresponding eld), with no action-leveltion 5c XML-parsing reference route and the downstream converter.ap generated rows to source steps, source parameters, conversion rules,ents, scaling factors, le hashes, and dropped-row status. The LLM-ow metadata onlyDigital DiscoveryDigital Discovery Papercompatible endpoint. The local runs were performed ona Windows 11 Pro (64-bit) workstation equipped with an AMDRyzen Threadripper 3990X processor, 128 GB of DDR4-3200memory, and an NVIDIA RTX PRO 6000 Blackwell Max-QWorkstation Edition GPU with 96 GB of VRAM, on which thegpt-oss-120b model was served through Ollama. The quali-tative behaviour was identical to that of gpt-4o-2024-05-13:the intermediate CSV exhibited the same class of minor white-space and numerical-formatting variations across runs, whileall ten nal *_converted.csv les produced aer the deter-ministic Stage 3 post-processing were byte-for-byte identical.These observations lead us to believe that output-layer deter-minism for the benchmark cases is not specic to the remotecommercial model and that an on-premises open-weight modelcan be substituted without loss of determinism in the nalconverted CSV les, although we emphasise that this behaviourhas been veried only for the four benchmark procedures andthe two models examined here. This is a practically importantobservation for laboratories that cannot transmit syntheticprocedure data to an external API.3.4 Robustness to input surface variationOne motivation for the LLM-assisted mapping stage stated inthe Introduction is tolerance of benign surface variation in thecDL input. To test this property directly rather than assert it,we constructed a perturbation benchmark from the fourbenchmark cDL les. Each le was subjected to three classesof deterministic, seed-controlled perturbations that preservethe chemical meaning of the procedure: (i) formattingperturbations, in which the XML is re-indented or collapsedonto fewer lines and the attribute order of the action elementsis permuted; (ii) lexical perturbations, in which unit spellingsand value spacing are varied (for example, min / minutes, h/ hours, mL / ml, and removal of the space betweena number and its unit); and (iii) typographical perturbations,in which realistic character-level typos are introduced intoreagent labels that do not participate in reux-temperatureresolution (for example, potassium carbonate / pota-sium carbonate). All three classes leave the correct nal CSVunchanged: for classes (i) and (ii) the canonical output isindependent of the serialization details and of the surfacespelling of the units (restoring the canonical unit spellings isthe task of the mapping stage, since the Stage 3 converteraccepts only the canonical forms), and for class (iii) only thereagent labels in the human-readable chemical-zone tablelegitimately differ while the execution CSV rows areunchanged. Two variants per class were generated for each ofthe four cases (24 perturbed inputs in total). Each perturbedle was passed through the complete LLM-assisted pipeline(gpt-4o-2024-05-13, temperature 0.2), and the resultingnal *_converted.csv was compared with the correspond-ing unperturbed reference output both byte-for-byte and at thelevel of parsed command sequences and numerical elds. Theperturbation generator, the evaluation script, and the per-turbed inputs are included in the soware archive (robust-ness_eval/), and the protocol is described in the SI.Digital DiscoveryAcross the 24 perturbed variants, 15/24 nal *_con-verted.csv les were byte-for-byte identical to the unper-turbed reference outputs (typographical class: 8/8; formattingclass: 6/8; lexical class: 1/8), and the same 15 were identical atthe parsed command-sequence and numerical-eld level. Thenine deviations fall into two well-dened groups, neither ofwhich silently altered the chemistry of an executable le. Sevenof the eight lexical variants were not normalised by the model:the perturbed unit surface forms (for example 16 hours and8.32 g) were echoed verbatim into the intermediate CSV, andthe deterministic Stage 3 converter then rejected each of theseles with an explicit unit-parsing error, so that these variantsfail loudly at conversion instead of producing an executableprogram; unit normalisation was not consistent across cases,since the remaining lexical variant (the spelled-out units ofv97p0054) was normalised correctly and passed byte-for-byte.The other two deviations are the formatting variants ofv97p0054, in which the dual-quantity Add of di-phenylphosphinic chloride (the source element carries bothmass=“50.0 g” and volume=“40.4 mL”; Section 5) isemitted through the gravimetric TrsG form instead of thevolumetric TrsV form of the reference run, the two encodingsbeing equivalent in reagent amount and both admitted by theformat description. Row-by-row inspection of the archivedvariant outputs shows that the deviation is conned to theencoding of this single addition and to the consequentrenumbering of the side-ask zone label in the rows thatreference it (the reagent is registered as solid-2 rather than asa liquid reservoir zone, which shis the sequential zonenumbering by one): every dispensed quantity, hold time, andtemperature setpoint, the recovered full-transfer volume of theside-ask contents, and the global scaling factor are identical tothe reference. Because the affected reagent is a liquid, thegravimetric encoding is operationally dispreferred, and thisvisible command-level change is exactly the class of deviationthat the operator audit of Section 3.5 is designed to catch. Thebenchmark complements the ten-run reproducibility analysisabove: reproducibility xes the input and varies the sampling,whereas the present benchmark xes the sampling regime andvaries the input surface.As a deterministic point of comparison, feeding the same 24perturbed inputs through the rule-based reference converter(xdl2chemspeed_rulebased.py) and the same downstreamconverter yields 16/24 byte-for-byte identical nal CSVs: allformatting and typographical variants are absorbed, becausethe XML parser is indifferent to serialization details and thezone assignment is independent of the label text, whereas alleight lexical variants fail during downstream conversion,because the deterministic route copies every unit surface formverbatim. Under the strict byte-for-byte criterion the two routestherefore perform comparably on this benchmark (15/24 versus16/24), with complementary failure surfaces: the deterministicroute is immune to formatting perturbation but structurallyincapable of absorbing lexical variation, whereas the LLM routeabsorbed one lexical variant, echoed the remainder, and intro-duced one admissible encoding ip under formatting pertur-bation. Both observed LLM-route shortfalls are addressable at© 2026 The Author(s). Published by the Royal Society of ChemistryPaper Digital Discoveryprompt level, which is the extensibility mechanism emphasisedthroughout this work: an explicit instruction in the Chemspeedformat description to normalise unit spellings to the canonicalforms, and an explicit precedence rule for dual-quantity Addelements (prefer the volumetric form when both mass andvolume are present), are one-line format-description updatesthat require no code change, and verifying their effect on thisbenchmark is identied as an immediate next step. Equallyimportant is the fail-safe character of the observed deviations:in no variant did the pipeline silently produce an executable lewith altered chemistry—the lexical failures abort at Stage 3 withexplicit errors, and the encoding ip is a visible command-typechange caught by the audit. The archived evaluation reports forboth routes are included in the soware archive.3.5 Hardware-conguration compatibility and operatorreviewCompatibility between a generated workow and a specichardware conguration is established at three levels in thepresent framework. First, the Chemspeed format descriptionthat accompanies the prompt enumerates only the commandtypes that the deployed conguration supports (Table 1); thecapability set of the installation is thus encoded in the formatdescription itself, and a procedure that requires operationsoutside this set cannot be expressed in the generated program—the corresponding actions surface as schema dropouts that areretained in the provenance sidecar rather than being emitted asunexecutable rows. Second, the physical addressability of thedeck is xed by a static template, as described in the nextparagraph. Third, no automated model of module availability,accessory conguration, or operational capability is currentlyimplemented: the nal compatibility judgement is delegated toan operator audit of the generated le.The logical identiers assigned by the converter (zone-1,solid-1, and so on) are bound to physical deck coordinatesthrough a static template dened inside xdl2chemspee-d_executar.app: each logical label corresponds to a xedrack position of the deployed deck layout (Fig. S2 of the SI).Dynamic physical auto-zoning is not supported in the presentimplementation. Adapting the pipeline to a different decklayout or rack population is therefore a once-per-deploymentedit of this template rather than a per-procedure operation.Beyond syntactic conformance, physical executability is notcertied automatically. Constraints such as viscous-liquiddispensing, foaming, solid owability in the gravimetricdispensing unit, vial headspace, and dead volumes are outsidethe scope of the loading heuristic of eqn (1), which is deliber-ately conservative rather than predictive. The optional ow-rateeld of TrsV rows provides a manual mechanism for slowingthe dispensing of viscous liquids, but its value is currentlyassigned by the operator rather than inferred from reagentproperties; automated property-aware parameterisation ofdispensing operations is identied as future work.We therefore emphasise that the transition from the gener-ated CSV to hardware execution is deliberately not fully auto-mated. An expert operator audits the generated le for chemical© 2026 The Author(s). Published by the Royal Society of Chemistrydelity and physical safety (ll volumes, dead volumes,dispensing limits, and reagent compatibility) before it is loadedinto xdl2chemspeed_executar.app. The statement that thecase-study program was executed “without manual modica-tion” (Section 4.5) therefore means that the operator audit didnot necessitate any edit of the generated le, not that the auditstep was skipped. The pipeline automates the translation of theprocedure, not the authorisation of its execution.4 Case study: benzylation of3,4-dimethoxyphenolTo illustrate the behaviour of xdl2chemspeed on a realisticliterature procedure, we applied the complete pipeline to thesynthesis of 4-benzyloxy-1,2-dimethoxybenzene reported as StepA in an Organic Syntheses article by Okaya, Okuyama, Okano,and Tokuyama.22 The article describes charging 3,4-di-methoxyphenol and potassium carbonate, adding MeCN, stir-ring at ambient temperature, adding benzyl bromide, washingthe reux condenser with MeCN, and then heating the reactionmixture to reux for 2 h. This fragment is well suited to thepresent proof-of-concept because it contains comma-bearingreagent names, both solid and liquid additions, a repeateduse of the same solvent, and a reux instruction that must betranslated into a workstation-oriented temperature eld (Fig. 3).4.1 Stage 1: cDL inputThe case-study input le v93p0063.xdl declares four reagententries, one reactor, and four source asks (one per reagent).Each reagent is given an internal identier of the form ri_name(where i is the reagent index in the cDL Reagents block); theseprexed identiers propagate through the intermediate CSVand the chemical-zone mapping table. The Procedure blockcontains eleven actions: two Add steps for solids, two Start-Stir declarations, two Stir steps with explicit times, twoliquid Add steps for MeCN, one liquid Add step for benzylbromide, one HeatChill step, and one StopStir step. Twopoints are important for accurate interpretation. First, the cDLinput already contains the 5 mL MeCN rinse as an explicit Addaction. Second, the HeatChill block already uses tem-p=“reux” rather than a numerical temperature. The presentcase study therefore tests preservation and downstreamhandling of these instructions rather than LLM recovery ofomitted information.4.2 Stage 2: LLM-assisted mapping to intermediate CSVThe mapping strategy of this stage is generalizable; only thetarget command vocabulary is Chemspeed-specic. The cDLle was passed to the LLM stage together with the static cDLand Chemspeed format descriptions. The resulting interme-diate CSV contained seventeen non-empty lines including theterminal END row, as reproduced in Listing 1. The outputexhibits three properties that are relevant to the presentmanuscript. First, both 3,4-dimethoxyphenol and potassiumcarbonate were mapped to the solid-transfer command TrsG,whereas MeCN and benzyl bromide were mapped to theDigital DiscoveryFig. 3 Reaction scheme for the case study that was adapted from theOrganic Syntheses source article.Digital Discovery Papervolumetric transfer command TrsV. Second, the 5 mL MeCNrinse appears in the intermediate CSV because it is presentexplicitly in the cDL input. Third, the comma-containing labelr1_3,4-dimethoxyphenol is retained as a quoted secondeld aer the dedicated post-processing step. The currentintermediate format does not preserve an explicit source-actionidentier for each generated row, which is an important limi-tation for future benchmarking. The Chemspeed formatdescription further species that a quantity-omitted cDLTransfer from an unsplit mixture vessel is recovered as thefull-transfer total-mixture volume (the sum of all explicit liquidAdd volumes plus solid-contribution volumes at an assumeddensity of 1 g mL−1), and that component-level recovery froma single Add with both volume and mass or amount is used onlyas a fallback when the total-mixture estimate is not justied.This convention is consistent with the natural chemical readingof a <Transfer> without an explicit transferred quantity and isexercised directly in cases v92p0328 and v97p0054 of Section 5.Listing 1 intermediate Chemspeed CSV aer LLM mapping(v93p0063.csv).The generated rows do not include optional ow-rate values,and the Stir rows leave the optional rotational-speed eldblank. These omissions are permitted by the Chemspeed formatdescription that accompanies the prompt. In the presentimplementation, correctness at this stage therefore meansconformance to the expected row schema and faithful retentionof the principal additions, waiting periods, and heatinginstruction from the cDL input.It is also instructive to compare the eleven cDL actions in theinput with the sixteen non-terminal rows of Listing 1. The cDLinput contains two explicit StartStir declarations and twotimed Stir steps, and the intermediate CSV therefore containsfour distinct Stir rows (rows 3, 5, 10, and 13 of Listing 1), inaccordance with the format-description rule that eachDigital DiscoveryStartStir and each timed Stir must emit its own dedicatedStir row rather than be absorbed into a neighboring event.Specically, row 3maps the rst StartStir, rows 5–7 form thecanonical Stir/Wait/StirOff triplet that expands the rsttimed Stir (10 min hold), rows 10–12 form the equivalenttriplet for the second timed Stir (20 min hold), and row 13maps the second StartStir that precedes the HeatChillstep. The three terminal StirOff rows (rows 7, 12, and 16)correspondingly close the two timed episodes and the nalStopStir tag. This row-level expansion is consistent with theformat-description rule and is captured by the deterministicprovenance sidecar of the rule-based reference route. In thatsidecar, rows 5–7 of the intermediate CSV are linked to the samesource Stir step, with distinct conversion-rule identiers forthe start, wait, and terminal StirOff rows. The LLM-assistedroute still requires operator inspection because it does not yetenforce deterministic source-step attribution without the rule-based cross-check or a verier-coupled alignment module.4.3 Stage 3: system-specic conversionStage 3 is the most platform-specic stage of the pipeline: theparameters below encode properties of the deployed worksta-tion rather than of the cDL representation. The intermediateprogram was then passed to Chem-speedSystemConverter.py. In the uploaded implementa-tion, the converter uses a maximum reactor load of 5.0 mL-equivalent, an assumed liquid density of rL = 0.80 g mL−1,and an assumed solid density of rS= 1.00 gmL−1. The converterrst aggregates all material directed to each destination zoneinto a common mass equivalent and then converts that aggre-gated mass to a volume equivalent through the assumed soliddensity. For a solid charge of massmi (g), the contribution to theaggregated mass is mi itself. For a liquid charge of volume Vj(mL), the contribution is VjrL (g). The total loading for a givendestination zone is thereforeVzone ¼Pi˛solidsmi þPj˛liquidsVjrLrS; (1)so that Vzone has units of millilitres. The division by rS = 1.00 gmL−1 is numerically trivial in the present implementation, butit is retained explicitly in eqn (1) to make the dimensionalreduction unambiguous. Throughout this paper we report theintermediate sum in the equation above in grams and the nalVzone in millilitres, which differ only in numerical label for thepresent choice of rS. For the reactor in the present case study,Vzone ¼ 8:32þ 8:29þ 95:0� 0:80þ 6:54� 0:80þ 5:0� 0:80 g1:00 g mL�1¼ 101:842 mL;(2)where the rst two terms are the solid masses of 3,4-di-methoxyphenol and potassium carbonate, and the remainingthree terms are the liquid charges of MeCN (two additions) andbenzyl bromide, each converted to a mass equivalent throughrL. The resulting scaling factor is© 2026 The Author(s). Published by the Royal Society of ChemistryPaper Digital Discoverys ¼ 5:0101:842¼ 0:049096.z 0:0491: (3)The converter retains the unrounded value internally; therounded form 0.0491 is shown here only for readability, and allnumerical values reported below are obtained from the full-precision factor. This factor is applied uniformly to the massand volume elds. In the present code path, the time elds areconverted to minutes and are not scaled. Thus, 10 min remains10.0000, 20 min remains 20.0000, and 2 h becomes120.0000. The converter assigns sequential identiers on rstuse, for example the reactor zone identier reactor1produced by the LLM mapping stage (the normalized form ofthe cDL Hardware element with id=“reactor”) becomeszone-1 in the nal CSV, and r1_3,4-dimethoxyphenolbecomes solid-1. Finally, the token reux is replaced by thehighest boiling point among matching solvent names found insolvent_bp_synonym_formula.csv. In the present case,the matching solvent is MeCN, which gives 81.6 °C.This stage should be interpreted carefully. The scaling modeldened by eqn (1) is a pragmatic loading heuristic with twoxed effective densities and a single maximum-volumethreshold. It is not a rigorous model of slurry rheology, deadvolume, heat transfer, concentration dependence, or reactor-specic engineering constraints. In particular, the assumedsolid density of rS = 1.00 g mL−1 is conservative for typicalorganic solids but underestimates the true density of inorganicbases such as K2CO3 (∼2.43 g mL−1), so the heuristic inten-tionally over-allocates effective volume to such reagents in orderto stay safely below the vial capacity. The liquid density of rL =0.80 g mL−1 plays the analogous role for commonly usedorganic solvents. The corresponding execution-format CSVshould therefore be regarded as a machine-oriented dra thatrequires operator review before deployment. Regarding thescale change itself, scale-down from a literature procedure iswell established in synthetic chemistry practice: whereas scale-up requires careful attention to mixing efficiency, thermaluniformity, and concentration gradients, scale-down generallyimproves these parameters and therefore poses fewer risks toreaction delity. The experimental outcome described inSection 4.5 supports this reasoning.4.4 Stage 4: nal Chemspeed program and chemical tableThe output of the full pipeline consists of the execution lesconsumed by the Chemspeed workow and separate audit les.The converted execution-format CSV (v93p0063_conver-ted.csv) is shown in Listing 2, and the accompanying chem-ical table (v93p0063_chem_table.csv) is shown in Listing 3.Together, these les provide a workstation-oriented sequence ofcommands and a human-readable mapping from internal zoneidentiers to the original reagent labels. The sidecar lesv93p0063_provenance.csv and v93p0063_converted_-provenance.csv provide the row-level audit trail and are notimported into the Chemspeed application.Listing 2 nal system-specic Chemspeed CSV(v93p0063_converted.csv).© 2026 The Author(s). Published by the Royal Society of ChemistryListing 3 chemical zone mapping table(v93p0063_chem_table.csv).A few numerical checks are instructive. The rst TrsG rowcorresponds to 8.32 × 0.049096 z 0.4085 g. The rst TrsV rowcorresponds to 95 × 0.049096 z 4.6641 mL. The rinse stepcorresponds to 5 × 0.049096 z 0.2455 mL. The waiting periodof 2 h becomes 120min in the converted le. The chemical tablealso shows that the original comma-containing reagent label ispreserved as quoted text in the human-readable mapping lewhile the internal identier used by the converted CSV issolid-1. These observations support the claim that the dedi-cated eld-protection step addresses a concrete parsingproblem in the selected case study.The nal provenance sidecar provides a row-by-row expla-nation of the transformation path from source cDL to thedevice-oriented CSV. Table 3 shows selected elds from therecord for the rst MeCN transfer in Listing 2. The full sidecarretains additional elds, including the output-eld JSON,intermediate-eld JSON, source-XDL, intermediate-le, andoutput-le SHA-256 hashes, the soware version, the chemical-zone table lename, and the name of the intermediate prove-nance le.The converted execution-format CSV produced at the end ofStage 3 is subsequently loaded into xdl2chemspeed_ex-ecutar.app, a companion application implemented in theChemspeed AutoSuite environment (AutoSuite version 2.29.1.1)that interfaces directly with the Chemspeed hardware. Theapplication reads the CSV le and dispatches each commandrow to the workstation sequentially in the order in which itappears in the le, translating each row into the correspondinghardware-level instruction (solid transfer, liquid transfer, stir-ring, heating, waiting, or program termination) via the Chem-speed instrument control layer. This row-by-row sequentialexecution model ensures that the reaction sequence encoded inthe generated CSV is faithfully reproduced on the physicalworkstation without requiring further manual reformatting ofthe output le. The binding of the logical zone identiers of theconverted CSV to physical deck positions inside this applicationfollows the static template described in Section 3.5.Digital DiscoveryTable 3 Selected fields from the row-level provenance record for output row 4 of v93p0063_converted.csvField Recorded valueoutput_row_id 4output_command TrsVintermediate_row_id 4source_step_id v93p0063:step:0004source_step_type Addsource_parameter Volumesource_value 95 mLintermediate_conversion_rule_id xdl_add_volume_to_trsvconversion_rule_id intermediate_trsv_to_chemspeed_trsv; source_zone_assignment;destination_zone_assignment; mL_to_mL_with_global_loading_scale; empty_rateoriginal_value source=r3_MeCN; destination=reactor1; volume=95 mL; rate=converted_value source=zone-2; destination=zone-1; volume=4.6641; rate=scaling_factor 0.04909565798Status OkDigital Discovery Paper4.5 Stage 5: hardware executionTo validate end-to-end operation beyond le generation, weloaded v93p0063_converted.csv into xdl2chemspee-d_executar.app and executed the program on a ChemspeedSWING workstation equipped with a temperature-controlled8 mL vial rack, a liquid dispensing unit, and a soliddispensing unit. The application dispatched each CSV row insequence to the workstation hardware without any furthermanual modication of the output le; in line with the policy ofSection 3.5, the generated le was audited by an operator beforeexecution, and the audit did not necessitate any edit. Thereaction was carried out at 2.65 mmol scale with respect to 3,4-dimethoxyphenol, corresponding to the quantities in the con-verted CSV aer global scaling. The Chemspeed enclosure usedin this study performs an instrument-level inert-gas purge of theentire deck rather than a per-vial EvacuateAndRell cycle.Under the standard nitrogen-purge procedure used in ourlaboratory, the residual oxygen concentration inside the enclo-sure is reduced to below 100 ppm as measured by an in-lineoxygen sensor, and we have separately conrmed that oxygen-sensitive organometallic transformations including palla-dium- and copper-catalysed cross-couplings proceed cleanly inthis atmosphere. The converted CSV therefore does not need toencode per-vial gas-exchange commands for reactions ofmoderate air sensitivity in this enclosure (see also Section 5).Aer the automated run, the reaction mixture was cooled toambient temperature and ltered through a 2 cm pad of Celite.The workup and purication steps described here were per-formed off-deck; the status of on-deck ltration and onlineanalysis in the present implementation is discussed in Section4.6. The transfer was completed by washing the reaction vialwith EtOAc (2 × 25 mL). The combined ltrate was concen-trated on a rotary evaporator under reduced pressure and driedin vacuo, then puried by silica gel column chromatographyusing 15% ethyl acetate/85% n-hexane as the eluent, followingthe procedure described in the original Organic Synthesesarticle.22 Thin-layer chromatographic analysis at the end of thereaction conrmed complete consumption of the startingmaterial. The target product, 4-benzyloxy-1,2-Digital Discoverydimethoxybenzene, was isolated in 84.4% yield (546.12 mgfrom a theoretical 647.4 mg). The 1H NMR spectrum wasconsistent with the literature values (see SI for the fullspectrum).The reported yield in the main procedure of the originalarticle is 90% at the 54 mmol scale used in the original OrganicSyntheses preparation, and Note 7 of the same article addi-tionally reports a half-scale (27 mmol) run that afforded theproduct in 86% isolated yield (5.70 g).22 The 84.4% (546.12 mg)isolated yield obtained here at 2.65 mmol scale is thereforecomparable to the half-scale literature value documented inNote 7, indicating that the present automated executionreproduces the literature yield within the expected scale-dependent range. TLC conrmed complete consumption ofstarting material, and the small remaining difference relative tothe half-scale literature value is attributable to scale-dependentrecovery losses during workup and purication of sub-gramsamples, including material retained on the Celite lter pad,residual material in the small reaction vial and on transferpipettes, and recovery losses during silica gel chromatography.These factors are not consequences of the automated synthesisstep itself. These results conrm that the pipeline generates anoperationally valid Chemspeed program from a literature cDLle without requiring any manual correction of the output CSV.4.6 Discussion of the case studyThe case study demonstrates end-to-end operation of thepresent pipeline on a published synthetic procedure, from cDLinput through intermediate CSV generation, system-specicconversion, and physical execution on a Chemspeed SWINGworkstation. The selective quotation step resolves a concreteCSV-formatting problem for reagent labels that containcommas. The hardware execution conrms that the generatedprogram is operationally valid without manual modication.At the same time, the case study makes the present limita-tions clear. First, although Section 5 extends le-generationtesting to four literature-derived cDL les and reports anexpert-curated step-level delity analysis in Table 5, only one ofthese has been validated by physical hardware execution. The© 2026 The Author(s). Published by the Royal Society of ChemistryPaper Digital Discoverydepth/breadth division adopted here, in which one case isexecuted on hardware and three additional cases are evaluatedfor translation delity against the source cDL, allows themanuscript to demonstrate both operational validity andbroader operation-class coverage within a single proof-of-concept. A larger corpus benchmarked on hardware acrossmultiple workstations remains a natural target for future work.Second, the LLM stage is prompt-based and is not coupled to anautomated verier that enforces one-to-one alignment betweencDL actions and output rows. The current case did not requirerecovery of omitted operations because the cDL le alreadycontained the rinse step and the reux token, and the four-casebenchmark in Section 5 likewise did not uncover action-levelmistranslations; nevertheless, a verier-coupled LLM variantthat ags missing or spurious rows against the cDL wouldmakethis guarantee explicit rather than observed, which becomesincreasingly important as the benchmark is extended to largercorpora. The deterministic rule-based route now provides row-level provenance for the benchmark outputs, but blind multi-annotator scoring against independently constructed refer-ence CSV les remains necessary before these sidecars can beused as a statistical delity benchmark. Third, the isolated yieldof 84.4% (546.12 mg) obtained at the present 2.65 mmol scale iscomparable to the half-scale (27 mmol) literature yield of 86%(5.70 g) reported in Note 7 of the original Organic Synthesesarticle,22 while the main-text 54 mmol procedure reports 90%;the present execution therefore reproduces the literature yieldwithin the expected scale-dependent range, and TLC conrmedcomplete consumption of starting material. For these reasons,the present manuscript should be interpreted as a proof-of-concept with transparent implementation detail, deterministicrow-level provenance for the reference conversion route,a quantitative step-level delity audit of the translation layeracross four literature cases, and experimental conrmation ofoperational validity for the selected case study.A related question is how the pipeline behaves when theinput procedure is incomplete, ambiguous, or only implicitlyspecied. The present architecture takes the position thatchemical ambiguity should be resolved upstream of the execu-tion layer: the cDL input is assumed to have been authored orreviewed by an expert, for example within our review-orientedconversion framework,18 so that xdl2chemspeed is notrequired to guess missing chemistry. Within this scope, thepipeline handles the following classes of underspecicationdeterministically. Quantity-omitted Transfer actions arerecovered by the full-transfer total-mixture rule described inSection 4.2. Optional elds such as stirring rate and ow rateare le blank, so that documented workstation defaults apply. Areux token whose solvent cannot be matched in the boiling-point table falls back to a documented default of 80.0 °C, andthis fallback is visible in the provenance record. The knownlimitations and failure cases of the current architecture are,correspondingly: cDL elements that lie outside the formatdescription are not emitted into the execution CSV (they areretained as schema dropouts in the provenance sidecar); oper-ations that are genuinely absent from the cDL input are notinvented by the pipeline, by design; and semantic ambiguity© 2026 The Author(s). Published by the Royal Society of Chemistrythat survives upstream review propagates into the generatedprogram and must be caught by the operator audit of Section3.5. The robustness benchmark of Section 3.4 quanties toler-ance to surface-level noise in the input; semantic incomplete-ness, in contrast, remains out of scope for automated recoveryin the present implementation.The present implementation also deliberately restricts thecommand vocabulary to synthesis operations. Although theworkstation conguration used in this study includes solid-phase-extraction/ltration modules and an online HPLC, welimited the translated operation classes to dispensing, stirring,temperature control, and timed holds in order to keep thetranslation layer and its validation transparent; the workup andpurication of the case study were accordingly performed off-deck (Section 4.5). Extending the Chemspeed format descrip-tion with ltration, phase-separation, and online-analysiscommands, together with the corresponding cDL mappingsand hardware validation, is a concrete next step that the two-stage architecture supports without structural change: a newcommand type requires one new row schema in the formatdescription and one new branch in the executor task tree.5 Multi-case benchmarkBefore turning to the individual cases, we clarify the epistemicstatus of this benchmark. The role of physical hardwareexecution in the present study is to establish that the auto-matically generated Chemspeed program is operationally validon the target workstation. Operational validity means that thepipeline produces a le which, when dispatched row by row byxdl2chemspeed_executar.app, runs to completion ona real Chemspeed SWING deck and affords the expectedproduct without manual editing. This role is discharged by thebenzylation case study of Section 4, in which the execution-format CSV was consumed by the instrument-control layerwithout any manual editing and produced the target compoundwith spectroscopic data consistent with the literature.Repeating a full hardware run for every additional cDL inputwould be informative for inter-batch reproducibility of theworkstation hardware itself, but it does not probe a distinctproperty of the translation pipeline: once the workstation hasbeen shown to accept and execute a pipeline-generated CSV fora non-trivial literature procedure, further validation effort ismost informative when it is directed at translation delityrather than at re-conrming hardware compliance.The complementary role of the four-case benchmark istherefore to expose the pipeline to the broader operation-classspectrum that a realistic Chemspeed workow must support:multi-reagent solid charges, cross-vessel transfers, sub-ambienttemperature setpoints, explicit stirring-rate control, andoptional cDL annotations whose status in the current Chem-speed schema we can then make transparent. This division ofroles between depth (hardware validation on one case) andbreadth (le-generation delity across four cases) is consistentwith standard practice in proof-of-concept translation frame-works for synthesis automation13,19 and is well matched to theaim of the present manuscript. To the three additionalDigital DiscoveryTable 4 Multi-case benchmark coverage. A check mark indicates that the operation class is present in the corresponding cDL input and wasfaithfully reproduced in the generated execution-format CSV. An em dash indicates that the operation class does not occur in that input; it doesnot indicate a missing or unfaithful reproduction. Every operation class that was present in an input was reproduced in the corresponding outputOperation class v93p0063 (ref. 22) v91p0027 (ref. 23) v92p0328 (ref. 24) v97p0054 (ref. 25)Solid transfer (TrsG), $2 reagents 3 3 3 —Liquid transfer (TrsV) 3 3 3 3Comma-bearing reagent label (ri_3,4-.) 3 3 — —Heat above ambient (HeatCool) 3 (reux) 3 (60 °C) 3 (110 °C) —Sub-ambient HeatCool — — — 3 (−10 °C)Explicit stir rate (rpm) — — — 3 (200)Timed stir / Stir/Wait/StirOff expansion 3 3 3 3Cross-vessel transfer (TrsV between zones) — — 3 3Multiple destination zones — — 3 3Digital Discovery Paperliterature-derived cDL procedures drawn from OrganicSyntheses we therefore apply the complete xdl2chemspeedworkow and evaluate the outputs as le-generation and parser-level delity checks rather than as independent experimentalvalidations. The four cases collectively cover the operationclasses summarised in Table 4.5.1 Step-level delity analysisTable 4 conrms that the pipeline reaches each of the targetedoperation classes. To provide a quantitative complement to thedeterministic row-level provenance sidecars now generated bythe reference conversion route, we additionally performeda retrospective expert-curated step-level delity analysis over allfour cases. The analysis used only artifacts that the pipelineitself produces (the intermediate CSV, the nal *_con-verted.csv, and the chemical-zone mapping table) togetherwith the original cDL input; no additional experimentalmeasurement was required. For each case, the authors manu-ally compared the source cDL procedure with the nalexecution-format CSV, and classied every cDL action into oneof three categories: (i) correctly expanded into the Chemspeedrow, triplet, or cross-vessel transfer specied by the formatdescription; (ii) a schema dropout, meaning that the action wastranslated correctly but is intentionally not emitted into thenal execution CSV because the current Chemspeed formatdescription does not expose a eld capable of carrying thecorresponding cDL annotation, which is therefore a docu-mented limitation of the target schema rather than a trans-lation error or a disqualication of a misformatted action (weuse the single term schema dropout for this categorythroughout the manuscript); and (iii) mistranslated, meaningthat the output row disagreed with the format description orlost information that the schema could in principle havecarried. In parallel, every reagent identier, zone assignment,temperature setpoint, hold time, stir rate, mass, and volumewas checked for faithful propagation through the mass-equivalent loading heuristic dened by eqn (1). The outcomeis summarised in Table 5.Aggregated over the four cases, 47 cDL actions were processedin total, of which 44 were correctly expanded and 3 were schemadropouts, i.e., intentionally omitted because the current Chem-speed schema has no corresponding eld (oneDigital DiscoveryEvacuateAndRell in v91p0027 and two Purge actions inv97p0054); no action was mistranslated. Interpreted as action-level metrics against the source cDL, this corresponds toa correctly-expanded rate of 44/47 (93.6%) and a schema-dropoutrate of 3/47 (6.4%), with the two categories together accountingfor all 47 actions. The schema dropouts are not producedincorrectly by the pipeline: they are not emitted into the nalexecution CSV because there is currently no Chemspeed eld toemit them into. The nal provenance sidecar neverthelessretains these dropped rows with status=-dropped_by_downstream_converter, which permits audi-tors to distinguish schema-level omissions from unobservederrors. The two of these limitations that have direct chemicalrelevance are addressed elsewhere in this paper: the absence ofper-vial inert-gas handling (EvacuateAndRell and Purge) isjustied operationally by the sub-100 ppm deck-level inertisationof the present workstation (Sections 2.1 and 4.5), and thedropwise attribute with explicit addition time has a concreteplanned implementation route through an optional ow_rateeld (Case v97p0054 below). We regard Table 5 as a transparentstep-delity audit that is now supported by deterministic row-level provenance les for the reference conversion route, whilekeeping an automated, multi-annotator evaluation againstindependently constructed reference CSVs as a natural next stepfor statistical validation.We note three caveats for interpreting this analysis honestly.First, it is a single-annotator expert-curated analysis performedby the authors rather than a blind comparison against inde-pendently constructed reference CSVs, so it cannot substitutefor inter-annotator agreement statistics. Second, because thepipeline is deterministic at the output layer (Section 3.3), thedelity values reported in Table 5 are run-invariant for theconverged *_converted.csv used by the workstation and aretherefore not averaged over independent LLM runs. Third, theanalysis covers action-level and parameter-level delity but notthe chemical adequacy of the reaction itself, which is thedomain of hardware execution and was established only for thebenzylation case study. With these caveats stated, Table 5supports the interpretation that the translation layer reportedhere is step-faithful within the current scope of the Chemspeedschema across all four benchmark cases, with remaining gaps© 2026 The Author(s). Published by the Royal Society of ChemistryTable 5 Expert-curated step-level fidelity analysis for the four benchmark cases, obtained by manual comparison of each .xdl input, inter-mediate CSV, and converted CSV. “Correctly expanded” refers to cDL actions that produced the expected Chemspeed row, triplet, or cross-vessel transfer. “Schema dropout” refers to cDL actions or attributes intentionally omitted because the current Chemspeed format descriptiondoes not expose a corresponding field; these are documented schema limitations rather than translation errors and are listed explicitly so that theoptional annotations not yet captured by the pipeline are fully transparent. “Mistranslated” refers to cDL actions whose output row is missing ordisagrees with the format description. Temperatures, hold times, stir rates, and cross-vessel transfers are listed in the units produced by theconverterFidelity item v93p0063 v91p0027 v92p0328 v97p0054cDL actions in procedure 11 12 10 14cDL actions correctlyexpanded11/11 11/12 10/10 12/14cDL actions omitted asschema dropouts0 1 (EvacuateAndRell, ×2cycles)0 2 (Purge ×2)Additional attribute-levelschema dropoutsNone None None dropwise=”True” on oneAddcDL actions mistranslated 0 0 0 0Reagent / zoneassignments4/4 7/7 4/4 4/4Temperature setpointspreservedReux / 81.6 °C 60 °C, 25 °C 0 °C, 110 °C −10 °C, 25 °CHold-time propagation (tomin)10, 20, 120 960 10, 960 15, 10, 1, 30Stir-rate propagation n/a n/a n/a 200 rpmCross-vessel transferpreservationn/a n/a Zone-2 / zone-3; 380.9 mL,scaled full transferZone-5 / zone-1; 90.4 mL,scaled full transferGlobal scaling applied to allmasses/volumes3 3 3 3Paper Digital Discoverylocalised entirely at the schema level rather than at the LLMmapping layer.The three additional cases are summarised below. The cor-responding execution-format CSV les are included in thesource archive accompanying this manuscript and are notreproduced here in full.5.2 Case v91p0027 (Sonogashira coupling23)The cDL input charges 2-iodobenzamide together with threecatalyst components (PPh3, CuI, Pd(OAc)2) into the reactor,followed by DMF, Et3N, and 1-hexyne. Aer StartStir andEvacuateAndRell (N2, two cycles), the mixture is heated to60 °C and held for 16 h. The generated CSV correctly maps thefour solid charges to four TrsG rows and the three liquids toTrsV rows. The StartStir declaration is emitted as its ownStir, zone-1, row, and the subsequent timed Stir step (16h) is then rendered as the canonical Stir/Wait/StirOff triplet(Stir, zone-1,/Wait, 960.0000/StirOff, zone-1) inaccordance with the format-description rule that requires eachexplicit StartStir and each timed Stir to emit its owndedicated Stir row. The StopHeatChill action is correctlytranslated into a nal HeatCool, zone-1, 25.0000 rowrepresenting the return to ambient temperature. As describedin Sections 2.1 and 4.5, the EvacuateAndRell step isintentionally not emitted into the converted CSV because theChemspeed SWING workstation used in this work performs aninstrument-level inert-gas purge of the entire deck, reducing theresidual oxygen concentration inside the enclosure to below100 ppm; we have empirically conrmed that oxygen-sensitiveorganometallic reactions, including Pd/Cu-catalysed couplings© 2026 The Author(s). Published by the Royal Society of Chemistryof the Sonogashira type considered here, proceed reliably underthis atmosphere. The converter therefore maps VacRell to anempty Chemspeed command in the current code path. Opera-tors using a workstation without enclosure-level inertisationwould need to supply this functionality through a differentmapping rule or a hardware-side procedure; we note this asa deployment-dependent design choice rather than a trans-lation defect.5.3 Case v92p0328 (Di Maso et al., Michael-addition step24)This case is drawn from the Di Maso Organic Syntheses proce-dure for 4-methyl-1-(2-(phenylsulfonyl)ethyl)-2,6,7-trioxabicyclo[2.2.2]octane and exercises a multi-vessel workow with anintermediate transfer between zones. The cDL input rstcharges water and maleic anhydride into a preparation vessel(mix_r1_s1), stirs for 10 min, transfers the resulting solutioninto the reactor, cools to 0 °C, charges sodium benzenesulnateand acetic acid, starts stirring, and then heats to 110 °C for 16 h.The generated CSV correctly distinguishes the preparation zone(zone-2) from the reaction zone (zone-3). The quantity-omitted cross-zone Transfer is recovered by the full-transfertotal-mixture rule specied in the Chemspeed format descrip-tion: the LLM sums the explicit liquid Add volume (water, 370mL) and the solid-contribution volume of the Add of maleicanhydride (10.9 g interpreted at a density of 1 g mL−1,contributing 10.9 mL) to give a transferred volume of 380.9 mL,which is emitted in the intermediate CSV as TrsV,“mix_r1_s1”, reactor1, 380.9 mL, and scaled by thedownstream converter to TrsV, zone-2, zone-3, 5.7517,.The converter cools the reaction zone to 0 °C as HeatCool,Digital DiscoveryDigital Discovery Paperzone-3, 0.0000 before the subsequent solid and liquidcharges, and translates the heating step to 110 °C as Heat-Cool, zone-3, 110.0000. The 10 min preparation-vesselhold is converted to Wait, 10.0000 and the 16 h reactorhold to Wait, 960.0000, as expected.5.4 Case v97p0054 (Step A, DPPH precursor25)This case is the most demanding of the four because itcombines a sub-ambient temperature setpoint, an explicit stir-ring rate of 200 rpm, a dropwise addition, and a side-askpreparation that must subsequently be transferred into themain reactor. The cDL input charges tert-butyl-N-hydrox-ycarbamate and dichloromethane into the main reactor,performs a Purge with nitrogen, starts stirring at 200 rpm,cools to −10 °C, dropwise-adds triethylamine over 10 min, thenperforms a second Purge on the side ask mix_r2_r4,charges diphenylphosphinic chloride and dichloromethaneinto the side ask, stirs briey, transfers the side-ask contentsinto the main reactor over 30 min, and nally releases bothstirring and temperature control. The generated CSV preservesthe Stir, zone-1, 200.0000 command with the explicitrate, sets HeatCool, zone-1, −10.0000, and represents theside-ask preparation as a separate destination (zone-5) intowhich diphenylphosphinic chloride is charged via TrsV,zone-4, zone-5 (the source cDL Add element carries bothmass=“50.0 g” and volume=“40.4 mL”, and the LLMselected the volume form in this run) and dichloromethane ischarged via TrsV, zone-2, zone-5. The quantity-omittedTransfer of the side-ask contents into zone-1 is thenrecovered by the full-transfer total-mixture rule as the sum ofthe two liquid Add volumes (40.4 mL + 50 mL = 90.4 mL) and isemitted in the intermediate CSV as TrsV, “mix_r2_r4”,reactor1, 90.4 mL, which the downstream converter scalesto TrsV, zone-5, zone-1, 1.5436, aer applying theglobal loading factor. The terminal StopStir and Sto-pHeatChill actions of the cDL are correctly emitted asStirOff, zone-1 and a nal HeatCool, zone-1, 25.0000row representing the return to ambient temperature, exactly asin the equivalent terminal block of case v91p0027. The twoPurge actions are rendered into the intermediate CSV asVacRell rows and are then omitted as schema dropouts bythe downstream converter for the same deck-level inertisationreason described in Sections 2.1 and 4.5. The dropwise nature ofthe triethylamine addition and the 30 min duration of the naltransfer are not currently encoded in the converted CSV becausethe Chemspeed format description in the present imple-mentation does not include an explicit dropwise ag oraddition-time eld on TrsV rows; instead, the intermediateCSV emits the TrsV row followed by a Wait row whose durationmatches the original addition time, which preserves the overalltiming but not the instantaneous slow-addition prole. This isa known schema-level limitation rather than a translation error,and dropwise support is identied as an immediate target forfuture work: the natural implementation route is to extend theChemspeed format description with an optional ow_rate (oraddition-time) eld on TrsV rows and to have the LLM populateDigital Discoverythat eld whenever the source cDL Add element carriesdropwise=“True” or an explicit addition time attribute,without any change to the Stage 3 deterministic post-processor.5.5 Discussion of the benchmarkAcross the four cases, the pipeline produces syntactically well-formed Chemspeed CSV les that preserve the principal addi-tions, holds, and temperature setpoints of the source cDL. Thestep-level delity analysis of Table 5 aggregates to 44 correctlyexpanded and 3 schema dropouts out of 47 cDL actions acrossthe four cases, with no mistranslations observed. Three obser-vations are worth highlighting. First, the timed-Stir expansionspecied in the Chemspeed format description is followeduniformly across all four cases: every timed Stir step in theinput is mapped to a canonical Stir/Wait/StirOff triplet, andevery explicit StartStir declaration is mapped to its owndedicated Stir row rather than being absorbed into a neigh-boring triplet, as required by the format-description rule thatforbids merging a StartStir and a subsequent time-boundedStir into a single Stir line. For vessels that accumulatemultiple stirring events (e.g. the reactor in v93p0063, which issubject to two StartStir tags and two timed Stir steps), theemitted CSV contains one Stir row per explicit stirring event,producing the corresponding count of visible Stir rows in theintermediate CSV. Second, optional cDL annotations such asdropwise=“True”, addition time, and inert-gas exchange(EvacuateAndRell in v91p0027 and Purge in v97p0054) areomitted as schema dropouts because the Chemspeed formatdescription does not currently provide corresponding elds,which Table 5 makes transparent on a per-case basis; capturingthese annotations would require both a richer Chemspeedschema and prompt updates, and a concrete implementationroute for the dropwise case is identied in the v97p0054description above. Third, the absence of observed mistransla-tions at the action level across all four cases, including the mostdemanding v97p0054 case with sub-ambient control and side-ask preparation, indicates that under the current promptand with low-temperature sampling the remaining gaps arelocalised entirely at the schema level rather than at the LLMmapping layer. Although the benchmark is intentionally limitedto four procedures, Table 5 provides a per-case step-delityaccounting that can be audited row by row against thesupplied source archive and the generated provenance sidecars.A larger, automated benchmark with blind multi-annotatorscoring against independently constructed reference CSVs,hardware validation of the additional cases, and a verier-coupled LLM variant that monitors action-level alignmentautomatically, are the natural next steps and are identied asfuture work in Section 4.6. As an orthogonal cross-check,feeding the same four cDL inputs through the deterministicrule-based converter xdl2chemspeed_rulebased.py intro-duced in Section 2.1 and then through the same Chem-speedSystemConverter.py post-processor yieldsintermediate and nal *_converted.csv les that are byte-for-byte identical to those of the LLM pipeline in all fourcases. The same route writes <stem>_provenance.csv and© 2026 The Author(s). Published by the Royal Society of ChemistryPaper Digital Discovery<stem>_converted_provenance.csv les for each bench-mark case, which conrms that the step-level delity reportedin Table 5 is not an artefact of the LLM stage but is inherent tothe format-description rules themselves and is now linked toexplicit row-level evidence.6 Significance for materialsacceleration platformsThe present soware extends our previous studies on structuredrepresentation and review into platform-level execution ona commercial materials-synthesis workstation. OSPAR provideda semantically grounded representation of synthesis actions.17The subsequent review framework improved the interpretabilityand correction of automatically converted procedures.18 Thesoware reported here adds an execution-oriented interfacethat links those structured procedures to a Chemspeed instal-lation, which is representative of commercial automationinfrastructure used in many materials accelerationplatforms.5,9,10This connection is important because structured proceduraldata become substantially more useful when they can betranslated into concrete robotic actions on hardware that isalready present in the laboratory. An cDL-centered representa-tion can function as a portable intermediate layer for synthesisknowledge across the community.13,14 A Chemspeed-orientedexecution layer can then convert this knowledge intocommands that are suitable for a commercial platform withoutrequiring laboratories to adopt Chemputer hardware or a fullybespoke robotic stack. Even in its current proof-of-conceptform, the present work therefore contributes to interopera-bility between literature mining, structured synthesis repre-sentation, and robotic execution in the context of materialsresearch.In addition, the soware architecture is compatible withcontinued improvement of upstream natural-language-processing modules. Improvements in transformer-basedaction-sequence models,16 LLM-based verier-assisted genera-tion,19 and our own review-oriented framework18 can be con-nected to the same downstream execution layer. Thismodularity is relevant for future closed-loop systems in whichliterature understanding, structured representation, and auto-mated execution are integrated into a unied workow.Finally, we state explicitly the expected usability of theframework beyond organic synthesis, and the limitations to beanticipated when transferring it. The operation classes exer-cised in this work—gravimetric solid dispensing, volumetricliquid dispensing, stirring, temperature control, and timedholds—are generic liquid- and solid-handling primitives ratherthan organic-synthesis-specic operations, and the sametranslation layer is therefore directly applicable to workowssuch as formulation and electrolyte screening, polymer andnanoparticle syntheses, and catalyst-precursor preparation onthe same class of hardware. Three limitations should be ex-pected in such transfers. First, the cDL action vocabulary andthe available extraction corpora are strongly oriented toward© 2026 The Author(s). Published by the Royal Society of Chemistryorganic-synthesis prose, so upstream literature-to-cDL conver-sion may require domain-specic annotation effort before thepresent layer can be used. Second, unit operations that arecommon in materials domains but absent from the currentcommand vocabulary—ltration and phase separation (Section4.6), calcination, thin-lm deposition, ball milling, and pro-longed slurry handling—require schema extensions and, insome cases, hardware beyond the present conguration. Third,the xed-density loading heuristic of eqn (1) and the dispensingassumptions of the liquid-handling unit are stressed by highlyviscous, heterogeneous, or gas-evolving media, and per-vialatmosphere control may be mandatory for moisture- oroxygen-sensitive inorganic syntheses in installations withoutenclosure-level inertisation (Section 3.5).7 ConclusionsWe developed xdl2chemspeed, a soware framework thattranslates literature-derived cDL procedures into Chemspeed-oriented execution-format programs. The framework buildsupon our previous studies on OSPAR and on the review ofautomatically converted structured synthesis procedures,17,18and it is designed to be integrated downstream of LLM-basednatural-language / cDL pipelines such as CLAIRify.19 Theuse of an LLM-assisted mapping stage at the cDL / Chem-speed step, rather than a purely rule-based translator, isa deliberate architectural choice that keeps the whole natural-language / cDL / Chemspeed chain homogeneous in itstreatment of the cDL action vocabulary and allows the mappingto adapt to new or rarely encountered cDL elements throughprompt-level updates alone. The present implementation readscDL les, generates intermediate Chemspeed instructionsthrough this LLM-assisted mapping stage guided by explicitformat descriptions, and converts the result into a workstation-oriented nal format through selective eld quotation,sequential zone renaming, reux-temperature substitution, andheuristic global scaling. Deterministic Stage 3 post-processingabsorbs the residual stochasticity of the LLM stage, as demon-strated by byte-for-byte identical nal CSVs across ten inde-pendent runs with both the remote gpt-4o-2024-05-13model and the on-premises gpt-oss-120b model. A pertur-bation benchmark over formatting, lexical, and typographicalvariants of the same four cDL inputs further quanties thetolerance of the LLM-assisted route to surface-level input vari-ation and documents the fail-safe character of the observeddeviations (Section 3.4).End-to-end validation was demonstrated by loading theautomatically generated program into xdl2chemspeed_ex-ecutar.app and executing it without manual modication ona Chemspeed SWING workstation at 2.65 mmol scale, affordingthe target product in 84.4% isolated yield (546.12 mg) withspectroscopic data consistent with the literature, comparable tothe half-scale (27 mmol) literature yield of 86% (5.70 g) reportedin Note 7 of the original Organic Syntheses article.22 A comple-mentary le-generation benchmark covering the case study andthree additional Organic Syntheses procedures (four cases, 47cDL actions in total) showed that the pipeline correctly handlesDigital DiscoveryDigital Discovery Papermulti-solid charges, sub-ambient HeatCool setpoints, explicitstirring rates, and cross-vessel transfers; a retrospective expert-curated step-level delity analysis across the same four casesclassies 44 cDL actions as correctly expanded and 3 as schemadropouts, intentionally omitted from the nal execution CSVbecause the current Chemspeed schema has no correspondingeld (one EvacuateAndRell and two Purge actions), withno action-level mistranslations observed, so that the remaininggaps are localised entirely at the schema level rather than at theLLM mapping layer. Inert-gas handling is delegated to theworkstation enclosure rather than encoded per vial, which isjustied by the measured sub-100 ppm oxygen level inside thedeck of the present Chemspeed SWING workstation understandard nitrogen purging and is consistent with the successfulexecution of oxygen-sensitive organometallic reactions in ourlaboratory under the same conditions; this remains a deploy-ment-dependent design choice for other installations. Exten-sion of the Chemspeed format description to support dropwiseaddition and explicit addition times, on-deck ltration/solid-phase extraction and online-analysis commands, hardwarevalidation of the three additional benchmark cases, verier-coupled LLM source-step alignment, and blind multi-annotator scoring over a larger corpus are the next targets forfuture work. As an architectural cross-check, we also imple-mented a purely rule-based deterministic converter,xdl2chemspeed_rulebased.py, that performs the cDL /intermediate CSV mapping by XML parsing and dictionary-based dispatch rather than by LLM inference, and we veriedthat feeding its output through the same downstream converterproduces intermediate and nal *_converted.csv les thatare byte-for-byte identical to the LLM-based pipeline outputacross all four benchmark cases. The rule-based route addi-tionally writes source-step provenance les, and the down-stream converter writes nal-output provenance les that retainunit conversions, zone assignments, scaling factors, soware-version metadata, chemical-zone table links, le hashes, anddropped-row status records without modifying the Chemspeedexecution CSV. This equivalence supports the interpretationthat the Chemspeed format description is semanticallycomplete for these procedures and claries that the LLM stagein the primary pipeline is retained for architectural homoge-neity with upstream natural-language / cDL LLM pipelinesand for prompt-level extensibility, rather than to compensatefor any unrecoverable ambiguity at the cDL / Chemspeedboundary. Within the scope demonstrated here, the frameworkprovides a practical and inspectable bridge between machine-readable synthesis procedures and commercial laboratoryautomation.Author contributionsY. N. contributed to conceptualisation, soware revision, vali-dation, formal analysis, investigation, writing of the originaldra, and review and editing. K. M. contributed to con-ceptualisation, soware development, data curation, validation,and review and editing. S. A. contributed to Chemspeed systemimplementation, hardware execution, validation, and reviewDigital Discoveryand editing. M. Y. contributed to supervision, conceptualisa-tion, project administration, and review and editing. All authorsapproved the manuscript and the submitted soware archive.Conflicts of interestThere are no conicts to declare.Data availabilityThe code and data supporting this article are openly available inthe GitHub repository yuuyanagata/xDL2Chemspeed athttps://github.com/yuuyanagata/xDL2Chemspeed and arearchived on Zenodo (concept DOI https://doi.org/10.5281/zenodo.20327326, which always resolves to the most recentversion). The release version used for this revised manuscriptis rev22-nal, archived under the version DOI https://doi.org/10.5281/zenodo.21358276. The archive containsxdl2chemspeed.py, xdl2chemspeed_rulebased.py,ChemspeedSystemConverter.py, prompt-description les,the solvent boiling-point table, the four benchmark cDL les,the generated intermediate CSV les, the generated convertedCSV les, the intermediate and nal row-level provenancesidecars, the reproducibility-run outputs, the perturbation-robustness evaluation kit (robustness_eval/) with theperturbed cDL inputs and evaluation report, the unit-conversion regression test, and the provenance regressiontest. The data supporting the experimental validation,including the detailed procedure and the 1H NMR spectrumof the isolated product, are included in the supplementaryinformation (SI). Supplementary information: experimentalprocedure for the automated synthesis of 4-benzyloxy-1,2-dimethoxybenzene (experiment v93p0063), including reagentquantities, the sequence of operations carried out on theChemspeed SWING workstation, and the post-run workupand purication steps. It also summarizes the row-levelprovenance sidecars that accompany the benchmark outputs.The 1H NMR spectrum of the isolated product recorded at 399MHz in CDCl3 is shown in Fig. S1. Fig. S2 presents the decklayout and zone arrangement of the Chemspeed platformused in this study. Fig. S3 shows a screenshot ofxdl2chemspeed_executar.app, illustrating thehierarchical task tree and the parameter elds by which eachcommand type is dispatched to the Chemspeed workstationhardware. The SI additionally documents the implementationdetails of the LLM-assisted route (client construction,sampling conguration, token-limit handling, eld-quotingpost-processing, and CSV-arity conventions). It also describesthe perturbation-robustness protocol and the correspondingevaluation scripts. See DOI: https://doi.org/10.1039/d6dd00301j.AcknowledgementsThis work was supported by JSPS KAKENHI (grant numbersJP23H03810 and JP23K18500) and by the JST Support for Pio-neering Research Initiated by the Next Generation (SPRING)© 2026 The Author(s). Published by the Royal Society of Chemistryhttps://github.com/yuuyanagata/xDL2Chemspeedhttps://doi.org/10.5281/zenodo.20327326https://doi.org/10.5281/zenodo.20327326https://doi.org/10.5281/zenodo.21358276https://doi.org/10.5281/zenodo.21358276https://doi.org/10.1039/d6dd00301jhttps://doi.org/10.1039/d6dd00301jPaper Digital Discoveryprogram (grant number JPMJSP2119). Part of this work wasadditionally supported by JST ERATO (grant numberJPMJER1903) and by the Institute for Chemical Reaction Designand Discovery (ICReDD) at Hokkaido University, establishedunder the World Premier International Research Center Initia-tive (WPI) of the Ministry of Education, Culture, Sports, Scienceand Technology (MEXT), Japan. A part of this work was furthersupported by the New Energy and Industrial TechnologyDevelopment Organization (NEDO) Project to Develop CommonPlatforms Supporting the Widespread Use of Hydrogen. Theauthors acknowledge the foundations established by ourprevious studies on OSPAR and structured procedure review,which enabled the present integration work. Duringmanuscriptrevision, AI-assisted editorial and code-review tools were usedfor language polishing, consistency checks, and identicationof soware defects. The authors reviewed all revised text, code,data, and conclusions and accept responsibility for the nalcontent.References1 F. Häse, L. M. Roch and A. Aspuru-Guzik, Trends Chem.,2019, 1, 282–291.2 E. Stach, B. DeCost, A. G. Kusne, J. Hattrick-Simpers,K. A. Brown, K. G. Reyes, J. Schrier, S. J. L. Billinge,T. Buonassisi, I. Foster, C. P. Gomes, J. M. Gregoire,A. Mehta, J. Montoya, E. Olivetti, C. Park, E. Rotenberg,S. K. Saikin, S. Smullin, V. Stanev and B. Maruyama,Matter, 2021, 4, 2702–2726.3 M. Seifrid, R. Pollice, A. Aguilar-Granda, Z. Morgan Chan,K. Hotta, C. T. Ser, J. Vestfrid, T. C. Wu and A. Aspuru-Guzik, Acc. Chem. Res., 2022, 55, 2454–2466.4 M. Abolhasani and E. Kumacheva, Nat. Synth., 2023, 2, 483–492.5 G. Tom, S. P. Schmid, S. G. Baird, Y. Cao, K. Darvish, H. Hao,S. Lo, S. Pablo-Garćıa, E. M. Rajaonson, M. Skreta,N. Yoshikawa, S. Corapi, G. D. Akkoc, F. Strieth-Kalthoff,M. Seifrid and A. Aspuru-Guzik, Chem. Rev., 2024, 124,9633–9732.6 C. Bayley, et al., Matter, 2024, 7, 2382–2398.7 S. Lo, S. G. Baird, J. Schrier, B. Blaiszik, N. Carson, I. Foster,A. Aguilar-Granda, S. V. Kalinin, B. Maruyama, M. Politi,H. Tran, T. D. Sparks and A. Aspuru-Guzik, DigitalDiscovery, 2024, 3, 842–868.8 A. V. Tobias and A. Wahab, R. Soc. Open Sci., 2025, 12,250646.© 2026 The Author(s). Published by the Royal Society of Chemistry9 B. P. MacLeod, F. G. L. Parlane, C. C. Rupnow,K. E. Dettelbach, M. S. Elliott, T. D. Morrissey, T. H. Haley,D. J. Dvorak, M. B. Rooney, J. R. Deeth, V. Lai, G. J. Ng,H.-W. Lee, S. Rocha, M.-A. Légaré, A. Balasubramaniam,F. Denes, G. Tom, D. Farano, H. Molero, M. R. Jones,S. Noormohammad, M. A. G. Koffas and C. P. Berlinguette,Sci. Adv., 2020, 6, eaaz8867.10 B. Burger, P. M. Maffettone, V. V. Gusev, C. M. Aitchison,Y. Bai, X. Wang, X. Li, B. M. Alston, B. Li, R. Clowes,N. Rankin, B. Harris, R. S. Sprick and A. I. Cooper, Nature,2020, 583, 237–241.11 L. M. Roch, F. Häse, C. Kreisbeck, T. Tamayo-Mendoza,L. P. E. Yunker, J. E. Hein and A. Aspuru-Guzik, Sci. Robot.,2018, 3, eaat5559.12 S. Steiner, J. Wolf, S. Glatzel, A. Andreou, J. M. Granda,G. Keenan, T. Hinkley, G. Aragon-Camarasa, P. J. Kitson,D. Angelone and L. Cronin, Science, 2019, 363, eaav2211.13 S. H. M. Mehr, M. Craven, A. I. Leonov, G. Keenan andL. Cronin, Science, 2020, 370, 101–108.14 R. Rauschen, M. Guy, J. E. Hein and L. Cronin, Nat. Synth.,2024, 3, 488–496.15 M. Šiaučiulis, C. Knittl-Frank, S. H. M. Mehr, E. Clarke andL. Cronin, Nat. Commun., 2024, 15, 10261.16 A. C. Vaucher, P. Schwaller, J. Geluykens, V. H. Nair,A. Iuliano and T. Laino, Nat. Commun., 2020, 11, 3601.17 K. Machi, S. Akiyama, Y. Nagata and M. Yoshioka, J. Chem.Inf. Model., 2023, 63, 6619–6628.18 K. Machi, S. Akiyama, Y. Nagata and M. Yoshioka, DigitalDiscovery, 2025, 4, 172–180.19 N. Yoshikawa, M. Skreta, K. Darvish, S. Arellano-Rubach,Z. Ji, L. B. Kristensen, A. Z. Li, Y. Zhao, H. Xu,A. Kuramshin, et al., Auton. Robots, 2023, 47, 1057–1086.20 M. Seifrid, F. Strieth-Kalthoff, M. Haddadnia, T.-C. Wu,E. Alca, L. Bodo, S. Arellano-Rubach, N. Yoshikawa,M. Skreta, R. Keunen and A. Aspuru-Guzik, DigitalDiscovery, 2024, 3, 1319–1326.21 S. Kim, et al., Nucleic Acids Res., 2025, 53, D1516–D1525.22 S. Okaya, K. Okuyama, K. Okano and H. Tokuyama, Org.Synth., 2016, 93, 63–74.23 N. Okamoto, K. Takeda and R. Yanada, Org. Synth., 2014, 91,27–38.24 M. J. Di Maso, M. A. S. Peter and J. T. Shaw, Org. Synth., 2015,92, 328–341.25 T. Benkovics, A. J. Neel, R. Zhao and G. J. Hughes, Org.Synth., 2020, 97, 54–65.Digital Discovery A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform A software framework for translating literature-derived tnqh_x03C7DL procedures into execution-format programs on the Chemspeed automation platform