SDL Composer and Loop Architecture

Design Decision

SDLX separates scientific reasoning, package composition, experiment-loop integrity, workflow execution, and device control. These concerns have different failure modes and must not share one mutable Agent state.

ASCEND
  -> autonomous hypothesis, campaign, and decision coordination

Composer
  -> skill and workflow-module selection
  -> semantic capability binding
  -> deterministic immutable PACE package generation

PACE
  -> loop-run integrity, package snapshot, evidence, Result Bundle, archive

LabFlow
  -> deterministic workflow DAG, waits, locks, approvals, cancellation

LabBridge
  -> devices, capabilities, operations, artifacts, Human Tasks, space, audit

Controllers / ESPHome
  -> device-native protocols, low-level I/O, result processing, safe actions

Historically, the term Loop Keeper described the responsibility now implemented by PACE. It is a role, not an additional service.

Why the Layers Matter

An autonomous research Agent should reason over hypotheses, parameters, evidence, and information gain. It should not compose experiments from GPIO, MQTT topics, robot poses, or vendor SDK calls.

Conversely, deterministic services should not decide whether a scientific hypothesis is promising. They should validate, execute, record, recover, and refuse unsafe or incomplete requests.

This separation lets SDLX replace a simulated instrument with a physical controller without changing the experiment package or the Agent's scientific reasoning.

Core Abstractions

Device Capability

A Device Capability is the smallest typed operation exposed by LabBridge.

Examples:

balance0.weigh
furnace0.run_heat_program
electrochemical-workstation0.run_lsv
amr1.navigate_to_station
manual_xrd0.upload_phase_analysis

Each capability declares:

• a stable semantic identifier;
• read or write direction;
• input and output schemas;
• agent-control and approval policy;
• timeout and cancellation behavior;
• expected semantic result fields;
• a controller implementation boundary.

Capabilities are appropriate for permission, state, schema, operation, and audit enforcement. They are usually too small to be the primary scientific composition unit.

Process Module

A Process Module is a reusable, scientifically meaningful operation composed of deterministic workflow steps.

Good module boundaries include:

prepare_rde_cell(sample_id, electrolyte, electrode_geometry)
heat_and_hold(sample_id, atmosphere, temperature_program)
dose_and_mix(sample_id, reagent, volume, mixing_program)
capture_and_inspect(sample_id, inspection_criteria)
move_carrier(carrier_id, source_station, target_station)
cleanup_or_safe_stop(station_id)

A module should expose:

• typed inputs and outputs;
• semantic capability requirements;
• required result fields;
• station, service-port, carrier, and lock requirements;
• risk and approval requirements;
• evidence and provenance references;
• safe-stop and failure behavior.

Single commands such as relay_on or sleep_5s belong at the capability or workflow-step layer. Entire campaigns such as optimize_formula belong at the ASCEND layer.

Composition

A Composition is a reviewed arrangement of Process Modules and parameters for one experimental candidate.

composition: orr_rde_lsv_round_03
  1. prepare_rde_cell
  2. condition_electrode
  3. run_lsv
  4. extract_orr_metrics
  5. archive_evidence

Composer may use an Agent to interpret research intent and select candidate modules. The final package is produced by deterministic code from validated module metadata, schemas, laboratory capability context, and bounded parameters. Model-generated YAML is never trusted directly.

Immutable PACE Package

The package is the executable and reviewable handoff from Composer to PACE. It contains:

pace.yaml
workflows/*.yaml
package id and hash
composition provenance
sample and planned conditions
semantic device bindings
result_contract.outputs
archive and incident policy

Once submitted, a package is immutable. Parameter changes create a new ASCEND Iteration and a new package hash.

Loop Run

A Loop Run is one evidence-producing execution of an immutable package. PACE records:

• research and process identifiers;
• hypothesis and planned conditions;
• package, module, and workflow versions;
• LabFlow run IDs;
• LabBridge operation, Human Task, artifact, and incident references;
• extracted facts, observations, and measurements;
• completeness and review status;
• the versioned Result Bundle consumed by ASCEND.

Composer Responsibilities

Composer accepts a scientific goal, selected skills, constraints, and candidate parameters through its formal job API:

POST /api/composer/jobs

Its pipeline is:

1. Read versioned skill evidence and Process Module metadata.
2. Read a bounded LabBridge capability snapshot.
3. Match module requirements by semantic identifier, required output fields, online state, station, and service port.
4. Refuse composition when a required semantic capability is unavailable.
5. Materialize workflow files and parameter bindings.
6. Generate a deterministic pace.yaml and package hash.
7. Validate the package and expose it for review.

Composer does not:

• execute experiments;
• manage Campaign state;
• decide the next scientific hypothesis;
• publish MQTT or call device SDKs;
• read ASCEND's database or import ASCEND's Python package;
• modify an already submitted package.

LabFlow Responsibilities

LabFlow is the workflow development and execution platform. It owns:

• strict workflow schemas;
• validation and preflight;
• DAG scheduling and joins;
• capability, adapter, bench, and spatial locks;
• approval steps;
• durable external-operation waits;
• bounded result data binding;
• retries, cancellation, safe-stop, and run export.

LabFlow does not own scientific campaign policy, experiment history, package composition, or device-native protocols.

PACE Responsibilities

PACE implements the Loop Keeper role. It owns:

• immutable package snapshots;
• Loop Run state and task bindings;
• LabFlow orchestration;
• result-contract completeness;
• facts, measurements, observations, evidence, incidents, and TODOs;
• process-scoped experiment history;
• pace-result-bundle/v1.

PACE treats a completed LabFlow run as necessary but not sufficient. A loop may still be incomplete if a declared scientific result or artifact is missing.

ASCEND Responsibilities

ASCEND is the Autonomous Scientific Campaign Engine for Novel Discovery. It provides policy-bound autonomy from hypothesis to evidence.

ASCEND:

• understands goals, samples, constraints, and acceptance criteria;
• proposes or accepts hypotheses and bounded candidates;
• requests Composer jobs;
• presents package and risk review;
• starts approved PACE runs;
• monitors authoritative downstream records;
• evaluates committed Result Bundles and process history;
• proposes and, when policy permits, applies the next Iteration;
• stops, blocks, or requests human action when evidence or policy requires it.

ASCEND does not become a second workflow engine or device gateway. Its autonomy is expressed through scientific decisions and campaign progression, not through bypassing deterministic execution controls.

Result and Data Flow

Device-specific output processing belongs to the controller implementing the capability. The controller converts native instrument output into:

compact semantic parameters
object-store artifact URIs
checksums and media types
method, software, and controller provenance

LabBridge validates the capability output schema before accepting a successful terminal operation. LabFlow carries operation references and bounded results. PACE extracts only package-declared result paths and builds the Result Bundle. ASCEND reasons over that committed bundle rather than downloading arbitrary raw files into the prompt.

Experiment Memory

PACE's process table is the current experiment-memory boundary. It supports queries such as:

• all rounds for one process or sample;
• planned versus observed conditions;
• measurements with units and provenance;
• artifact and incident history;
• completeness and review state;
• source package and workflow versions.

A future analytical warehouse may index the same records for large-scale modeling, but it must preserve immutable source references rather than replacing PACE as the run authority.

Repository Mapping

ascend/
  independent nanobot, Campaigns, Iterations, policies, decisions, Web UI

composer/
  skills, workflow pool, semantic binding, package builder, review jobs

pace/
  package loader, Loop Runs, result contracts, process table, Result Bundles

labflow/
  workflow schemas, editor, runner, waits, locks, spatial resources, exports

labbridge/
  device registry, SimFleet, Human Tasks, operations, artifacts, MCP, Admin Web

firmware/
  deterministic ESPHome I/O nodes and MQTT manifests

Current Demonstrations

Powder, Heat, and XRD

The package covers weighing, heat treatment, operator-assisted XRD data upload, deterministic phase analysis, artifact preservation, and result archival.

ORR RDE LSV

The package covers operator-assisted electrochemical cell preparation, semantic workstation binding, automated LSV execution, literature-backed local SOP parameters, and result extraction.

Spatial Robot Transfer

The tested contract covers map revisions, stations, service ports, resource leases, source-custody checks, route or station-mode execution, lease renewal, and successful custody transfer.

Design Constraints

1. Scientific reasoning never directly controls GPIO, MQTT, poses, joints, or vendor SDKs.
2. Simulation and physical execution share one capability contract.
3. Human Tasks are typed data-producing operations, not approval notes.
4. Long waits are persisted; they do not hold an HTTP request open.
5. Package and result schemas are versioned.
6. Successful operations must satisfy declared output schemas.
7. A new experimental candidate creates a new immutable Iteration.
8. Automatic progression is bounded by parameter limits, maximum iterations, risk policy, evidence requirements, and package approval.
9. Every user-visible aggregate state links to authoritative downstream IDs.
10. Missing evidence is explicit and cannot be converted into success by Agent narrative.

Delivery Priorities

1. Implement physical-controller idempotency and uncertain-state reconciliation.
2. Calibrate the first physical robot map and station-mode bindings.
3. Replace selected simulated controllers without changing modules or packages.
4. Connect trusted identity headers to the deployment identity provider.
5. Expand scientific analysis tools while keeping Result Bundle inputs bounded and provenance-preserving.