SDLX Autonomous Experiment Lifecycle and Hybrid Automation PRD

Status: implementation baseline
Updated: 2026-07-13
Primary owner: ASCEND

1. Purpose

SDLX turns a scientific objective into a governed sequence of executable, observable, and repeatable experiments. The platform must support both fully automated instruments and devices that require an operator to supply data or perform a physical action before execution can continue.

The product is organized around three additions to the existing execution stack:

• ASCEND, the Autonomous Scientific Campaign Engine for Novel Discovery, autonomously coordinates scientific campaigns and decides what should happen next.
• SimFleet provides maintainable virtual implementations of device capability contracts so workflows can be developed before physical hardware is available.
• Human Tasks convert manual work into durable, traceable operations rather than undocumented pauses outside the system.

The target lifecycle is:

Researcher objective
  -> ASCEND conversation and campaign policy
  -> Composer creates a reviewed PACE package
  -> PACE controls the experiment loop
  -> LabFlow schedules the workflow
  -> LabBridge calls physical, simulated, or human-assisted devices
  -> controllers return parameters and object-store artifact references
  -> PACE publishes a Result Bundle
  -> ASCEND evaluates the evidence
  -> next iteration, stop, request human review, or block safely

ASCEND's product position is:

Policy-bound autonomy from hypothesis to evidence.

Human involvement is a governance, safety, or physical-execution boundary. It is not the default source of planning or control.

2. Current Delivery Status

The implementation baseline as of 2026-07-13 is:

Area	Status	Delivered boundary
Common device calls	Complete	One capability and operation contract for controller, MQTT, simulated, and human-assisted devices
SimFleet	Complete	31 built-in profiles, YAML import/edit, grouping, enable state, deterministic behavior, and robot state
Human Tasks	Complete	Durable task lifecycle, immutable revisions, artifacts, review, rejection, cancellation, and Admin Inbox
Semantic package binding	Complete	Composer binds semantic requirements to available capabilities without a simulation branch
Spatial registry	P0 complete	Maps, stations, service ports, placements, leases, and carrier custody
Golden Loop exemplars	Complete	Powder/XRD and ORR RDE LSV packages with result propagation
ASCEND campaign control	P0 complete	Independent nanobot, chat, campaigns, iterations, policies, decisions, notifications, and Result Bundle consumption
Identity boundary	Basic complete	Trusted-proxy identity, viewer/operator/admin roles, and service tokens
Physical fleet rollout	Pending	Physical AMR, AGV, arm, and instrument adapters must adopt the validated contracts
Physical recovery	Pending	Controller idempotency and custody reconciliation are required before automatic robot-work recovery

The software P0 is approximately 93% complete. Production readiness is lower, approximately 72%, because physical integration, deployment identity, outbound notifications, calibration, and recovery behavior still require validation.

3. Product Principles

3.1 Autonomous, not monolithic

ASCEND owns campaign intent and next-round decisions. It does not absorb the responsibilities of Composer, PACE, LabFlow, LabBridge, or device controllers. Autonomy is achieved through explicit APIs and durable state, not by allowing one agent to bypass subsystem contracts.

3.2 One execution contract

A workflow calls a semantic capability. Whether the capability is implemented by a real instrument, SimFleet, or an operator-assisted controller is a deployment choice. Packages must not contain if simulated branches.

3.3 Manual work is a first-class operation

A Human Task is not a generic approval dialog. It represents missing physical work, data, or interpretation required by a capability. The parent operation remains nonterminal until a valid immutable submission is accepted.

3.4 Durable waits instead of long requests

No HTTP request should remain open while an instrument runs or an operator works. Operations, workflow waits, Human Tasks, and campaign iterations are persisted and reconciled after service restart.

3.5 Deterministic simulation

Virtual devices are versioned YAML profiles with strict schemas, stable capabilities, explicit output models, and configurable fault injection. An LLM does not invent device behavior during workflow execution.

3.6 Evidence before prose

Controllers normalize native outputs. LabBridge validates the declared output schema. PACE returns a typed Result Bundle containing compact parameters, artifact URIs, and provenance. ASCEND reasons over that contract instead of scraping logs or decoding device-specific files.

4. Authority and Module Boundaries

4.1 ASCEND

ASCEND is the autonomous campaign coordinator. It owns:

• researcher conversation and objective capture;
• campaign policy, scientific constraints, and stop conditions;
• immutable iteration candidates and their lineage;
• Composer job requests and package references;
• execution approval references required by policy;
• PACE launch, monitoring, and cancellation requests;
• Result Bundle evaluation and decision proposals;
• next-iteration, stop, human-review, and blocked decisions;
• persistent campaign notifications and cross-module references.

ASCEND does not own raw workflow execution, device protocols, artifact bytes, or per-device result parsers.

4.2 Composer

Composer converts a defined experimental intent into a reviewable PACE package. It owns skill selection, semantic capability binding, package generation, validation, and package review. It returns packages through its job API and does not control campaign state.

4.3 PACE

PACE is the loop execution authority. It owns immutable loop packages, process records, evidence, incidents, diagnostics, and pace-result-bundle/v1. It starts and observes LabFlow runs but does not decide the scientific campaign.

4.4 LabFlow

LabFlow is the workflow authority. It owns DAG scheduling, parallel and join semantics, locks, safe stop, durable external waits, data bindings, and spatial lease bundles. It calls capabilities through LabBridge.

4.5 LabBridge

LabBridge is the device and operation authority. It owns registry visibility, capabilities, controller routing, operations, artifacts, Human Tasks, SimFleet, spatial records, audit, MCP tools, and Admin Web.

4.6 Device controllers

Each controller owns its native protocol and native result processing. It translates device output into the capability's declared result schema and uploads large data to object storage. This prevents ASCEND, PACE, and LabBridge core code from accumulating one parser per instrument.

5. ASCEND Product Requirements

5.1 Conversation to campaign

ASCEND must be able to:

1. clarify the research objective, measurable response, constraints, resources, and acceptable risk;
2. record unresolved assumptions instead of silently filling them;
3. create a campaign with a versioned automation policy;
4. request Composer to create the first package;
5. present the package and required approvals when policy requires them;
6. start PACE and monitor the resulting execution references;
7. evaluate each Result Bundle against the objective and stop conditions;
8. autonomously create the next iteration while all policy checks pass.

5.2 Campaign and iteration state

Campaigns are durable containers. Iterations are immutable scientific candidates linked to one package and at most one execution attempt at a time. Required references include:

• campaign_id and iteration_id;
• composer_job_id and package URI or package identifier;
• pace_loop_run_id and labflow_run_id;
• LabBridge operation and Human Task IDs;
• artifact, incident, approval, and decision IDs;
• parent iteration and hypothesis lineage.

The Web UI must expose these references without forcing an operator to inspect multiple databases.

5.3 Automation policy

The initial policy contract is:

{
  "max_iterations": 10,
  "auto_decide": false,
  "auto_compose": false,
  "require_decision_approval": true,
  "require_package_approval": true,
  "parameter_bounds": {},
  "stop_conditions": []
}

The policy is evaluated by deterministic code. The agent may propose values, but it cannot expand parameter bounds, increase the iteration limit, ignore a stop condition, or remove an approval requirement during execution.

5.4 Autonomous decisions

After a completed Result Bundle, ASCEND may propose:

• next_iteration: modify the hypothesis or bounded experimental parameters;
• stop: objective reached, diminishing value, or iteration limit reached;
• request_human: scientific ambiguity, policy requirement, or exceptional physical action;
• blocked: missing capability, invalid evidence, unsafe state, or failed dependency.

Every decision records the evidence references, concise rationale, proposed changes, policy evaluation, model/runtime provenance, and final disposition.

5.5 Human oversight

Human approval remains appropriate for initial package execution, hazardous changes, out-of-bounds parameters, destructive actions, and policy-defined scientific checkpoints. Routine monitoring, result collection, and safe in-bound iteration should remain autonomous when enabled by campaign policy.

5.6 Notifications

ASCEND must persist notifications for:

• package ready for review;
• execution waiting for approval;
• Human Task requiring action;
• instrument or workflow failure;
• evidence inconsistency;
• proposed next iteration;
• campaign completion or policy stop.

P0 provides an in-product notification view. Email, webhook, and enterprise chat delivery are later deployment integrations.

6. SimFleet Requirements

6.1 Profile model

Every virtual device is defined by a versioned YAML profile containing:

• stable device identity and display metadata;
• controller template and profile version;
• semantic capabilities and input/output schemas;
• deterministic duration and output behavior;
• state and telemetry model;
• optional station, service-port, route, and carrier behavior;
• configurable deterministic faults;
• default group and default enabled state.

Unknown template, profile, capability, or execution fields must fail validation. Built-in profiles are system-maintained examples; custom YAML uses the same schema and remains editable.

6.2 Admin experience

LabBridge Admin must provide:

• one-click import of all built-in profiles into their default groups;
• visible YAML for both built-in and custom profiles;
• create, edit, validate, enable, disable, and delete actions;
• delete-all for virtual devices without deleting physical devices;
• preservation of group and metadata while a device is disabled;
• device ordering by physical before simulated, enabled before disabled, then alphabetical within each section;
• bounded scrolling and responsive rendering for large fleets.

Disabled devices remain registered but are hidden from agent-visible capability discovery and do not count as enabled or online. Their profile, group, spatial placement, and historical records remain intact.

6.3 Capability fidelity

A profile is useful only when it supports the same contract expected from the future physical controller. It must model:

• validation and state preconditions;
• asynchronous operation lifecycle;
• successful typed outputs;
• artifact URI and provenance fields where applicable;
• cancellation and safe stop;
• offline, timeout, invalid-result, and device-fault paths;
• idempotency behavior expected by retrying schedulers.

6.4 Mobile equipment

AMR, AGV, fixed-arm, and mobile-manipulator profiles must expose controller state rather than requiring LabBridge to infer it. At minimum this includes current station, target station, motion state, carried material identity, custody revision, battery or readiness where relevant, and last report time.

Robot actions are selected by semantic command plus station mode. A controller may implement a small set of verified local routines, such as dock, load, unload, operate panel, or service instrument. The scheduler selects the target station and allowed mode; it does not issue raw motor coordinates.

7. Human-Assisted Device Requirements

7.1 Generic controller

Human-assisted devices use a reusable controller template. Invoking a capability creates both a LabBridge operation and a Human Task. The operation does not complete until a valid task revision is accepted.

Example uses include:

• upload an XRD phase-analysis report;
• confirm a manually prepared electrochemical cell;
• supply an instrument export from equipment without a network API;
• record a measured value or structured checklist;
• perform a physical intervention that cannot yet be automated.

7.2 Submission contract

A task revision binds:

• operation, capability, device, run, step, and sample identity;
• required JSON schema and submitted structured values;
• artifact role, media type, checksum, object URI, and original filename;
• operator identity and timestamps;
• immutable revision number and idempotency key;
• review disposition and rejection reason.

Accepted revisions are immutable. A rejection creates a new submission path; it does not overwrite prior evidence. A deployment may permit one authenticated operator to submit and confirm the same revision when policy uses manual_accept.

7.3 Inbox behavior

The Admin Inbox must support list, filtering, detail, claim, upload, submit, accept, reject, resubmit, and cancel. The operator should see required fields, expected artifacts, sample identity, related run, and timeline in one view.

8. Durable Workflow Waits and Data Binding

LabFlow supports completion.mode=operation_terminal. After dispatch it stores the external operation ID, releases the HTTP request, and reconciles the operation until a terminal state is reached. Restart must resume this wait from the database.

The workflow result can bind later step inputs through a restricted $from contract. Initial sources are limited to:

• run.parameters.*;
• typed outputs of completed steps.

Arbitrary expressions, host paths, environment variables, and unrestricted template execution are not allowed.

Cancellation must propagate from ASCEND through PACE and LabFlow to active LabBridge operations and Human Tasks. A rejected Human Task remains a recoverable waiting condition until resubmitted or cancelled.

9. Result and Data Chain

The result path is intentionally generic:

Native device data
  -> controller processing and object-store upload
  -> LabBridge output-schema validation
  -> LabFlow typed step result and references
  -> PACE pace-result-bundle/v1
  -> ASCEND evidence evaluation

Small semantic values are returned inline. Large, binary, or instrument-native files are returned as object-store URIs with checksums, media types, roles, and provenance. Raw file bytes must not be copied through campaign records or LLM prompts.

ASCEND consumes the Result Bundle and PACE process facts. It must not read Composer working directories, scrape LabFlow logs, or import instrument parsers.

10. Spatial Registry and Flexible Robotics

10.1 Map model

A map revision contains a replaceable two-dimensional floor-map asset and a coordinate frame. Devices can be placed by selecting a registered device and clicking the map. The placement stores display coordinates and optional orientation without changing the device identity.

This direct placement answers the operator's need to place any of many devices quickly. Stations remain a separate semantic layer because robots need stable, validated destinations rather than arbitrary pixels.

10.2 Stations and service ports

A station represents a robot-addressable location. It may define:

• one or more service ports;
• allowed robot or payload classes;
• controller-local operation modes;
• occupancy and approach constraints;
• a calibrated physical pose hidden from general agent context.

Devices can be shown anywhere on the map without being stations. A station is created only when scheduling, docking, handoff, or a verified local robot routine requires one.

10.3 Map visualization

The map view should display:

• compact status markers at device placements;
• richer identity, group, capability, status, and last-update data on hover;
• robot last-reported station or placement;
• robot motion state and target station while moving;
• stale-state indication when reports exceed a configured age.

The UI is an operational overview, not a real-time localization system. A robot controller reports arrival at known stations and state transitions; the map does not invent intermediate positions.

10.4 Lease and custody

LabFlow acquires expiring leases for robot, station, port, and carrier resources before a step. It renews them while work is active, checks source custody, and commits a revisioned custody transfer only after verified success. Uncertain physical failure moves custody to an unknown state requiring reconciliation.

Automatic recovery of interrupted physical transfers is out of P0 until controllers provide idempotent commands and authoritative custody queries.

11. Golden Loop Exemplars

11.1 Powder heat and characterize

The reference package performs weighing, heating, operator-assisted XRD result submission, deterministic phase evaluation, and archival. It proves that a Human Task can pause an operation and that accepted structured data and artifacts flow into a PACE Result Bundle.

11.2 ORR RDE LSV

The reference electrochemistry package performs operator cell preparation and then calls electrochemical-workstation0.run_lsv. Literature evidence and local SOP parameters are explicitly separated. The package proves semantic binding and mixed human/automated execution.

11.3 Required fault scenarios

Acceptance coverage includes:

• Human Task rejection and resubmission;
• cancellation at campaign, loop, workflow, operation, and task levels;
• LabBridge restart while an external operation is waiting;
• stale MCP session reinitialization;
• invalid controller result rejection;
• offline or disabled device preflight failure;
• lease conflict and uncertain carrier custody;
• ASCEND stop, request-human, and blocked decisions.

12. API and Storage Boundaries

Key service boundaries are:

Service	Required API surface
ASCEND	chat, campaigns, iterations, automation policy, decisions, references, notifications, launch/cancel
Composer	create and inspect package-generation jobs; return reviewed package references
PACE	register package, start/cancel/poll loop, processes, evidence, incidents, Result Bundle
LabFlow	validate, preflight, start/cancel/poll/export run; persist steps and external waits
LabBridge	registry, capabilities, operations, Human Tasks, artifacts, spatial resources, audit, MCP

Each service owns its database and identifiers. Cross-module records store references, not duplicated mutable state. APIs must be idempotent where a caller may retry after timeout.

13. Safety, Identity, and Data Quality

• Viewer, operator, and admin permissions apply to device control, Human Tasks, registry changes, and spatial changes.
• Service-to-service calls use scoped service credentials.
• Trusted identity headers are accepted only behind a proxy that removes untrusted client-supplied values.
• Capability input and output schemas are validated at the authority boundary.
• Dangerous actions require declared policy and a verified safe-stop path.
• Every action records actor, service, request reference, timestamp, and result.
• Artifacts include checksum, media type, role, provenance, and sample binding.
• Agent-visible tools expose semantic commands and station identifiers, not raw GPIO, PWM, motor, or calibrated robot pose controls.

14. P0 Acceptance Criteria

P0 is accepted when all of the following hold:

1. A researcher can create a campaign and reach a reviewed executable package through ASCEND and Composer.
2. ASCEND can start, monitor, evaluate, and propose the next bounded iteration without direct database or filesystem coupling to other modules.
3. The same package can bind a compatible physical or simulated capability without changing workflow logic.
4. A human-assisted operation survives restart, accepts versioned structured data and artifacts, and resumes the workflow after acceptance.
5. PACE returns a typed Result Bundle with parameters, artifact URIs, and provenance sufficient for ASCEND's decision.
6. Disabled devices disappear from agent discovery while configuration, grouping, placement, and history remain preserved.
7. Mobile work acquires robot, station, port, and carrier leases and commits custody only after verified success.
8. Cancellation and restart recovery are covered by cross-process tests.
9. Campaign policy deterministically constrains automatic iteration count, parameter bounds, stop conditions, and approval requirements.
10. The UI exposes pending human work, campaign state, device state, and cross-module references without log inspection.

15. Deferred Production Work

The following work is intentionally outside the current P0:

• organization-owned OIDC, account lifecycle, and policy administration;
• automatic recovery of interrupted physical robot transfers;
• full calibrated map authoring and localization telemetry;
• outbound ASCEND notifications;
• broad physical controller rollout and instrument-specific certification;
• fleet optimization, traffic control, and continuous robot path rendering;
• unrestricted autonomous parameter exploration outside approved policy;
• direct LLM access to raw device protocols or artifact bytes.

These are deployment and scale milestones. They do not require changing the core separation between ASCEND, Composer, PACE, LabFlow, LabBridge, and device controllers.