SDLX Autonomous Experiment Lifecycle and Hybrid Automation PRD

Status: Historical — superseded by docs/agent-first-system-design-prd.md Updated: 2026-07-17 Primary owner: ASCEND Scope: Historical pre-PRISM Golden Loop P0

Archive note: this file preserves the accepted pre-PRISM Golden Loop P0 scope and its historical acceptance denominator. It is not a current roadmap or the source of present implementation status.

Scope note: this document measures the pre-PRISM Golden Loop P0. The approved independent data-analysis loop is tracked separately in docs/archive/prds/pace-prism-ascend-closed-loop-prd.md; its work must not be included in the 93% figure below. ASCEND's primary-interface rule, downstream Engineering Console boundary, and anti-hardcoding requirements are specified in docs/archive/prds/ascend-primary-interface-prd.md.

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 Coordination Engine for Novel Discovery, autonomously coordinates iterative scientific work 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 coordination 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 commits a Result Bundle and immutable delivery archive
  -> PRISM analyzes the delivery with analysis-only Skills
  -> PRISM commits a structured Analysis Result and archive
  -> ASCEND evaluates the committed analysis
  -> 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-17 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 coordination control	P0 complete	Independent nanobot, chat, coordinations, iterations, policies, PRISM Analysis Result decisions, and a durable global Attention Inbox
Cross-module attention and approval	P0 complete	Canonical event/decision schemas, source authentication, durable Composer, PACE, and LabFlow outboxes, PRISM lifecycle events, audited ASCEND routing, policy-bound package approval, stable action identity, restart-safe waits, and deduplicated Human Task notices
PRISM analysis loop	P0 complete	Independent nanobot, Analysis Skills, controlled sandbox, structured result, archive, callbacks, and Web
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. These percentages describe this document's pre-PRISM scope only. The separate PACE-PRISM-ASCEND software release gate is now 100% complete, bringing the combined approved software P0 to approximately 93-95%.

3. Product Principles

3.1 Autonomous, not monolithic

ASCEND owns coordination 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 owned by LabBridge. Composer, PACE, LabFlow, PRISM, and ASCEND must not receive or branch on that implementation type; packages contain no 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.

Bound task context and trusted actor identity are server-owned. Operators do not re-enter sample IDs, method IDs, approval names, or caller-asserted *_confirmed=true fields. An accepted preparation operation can authorize a direct downstream LabFlow action through authorization_from; the signed workflow context preserves the operation, Human Task, and source-step IDs.

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 coordination 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 preserve native outputs and upload large artifacts. LabBridge validates capability-level output contracts. PACE returns a typed Result Bundle and immutable delivery archive containing parameters, artifact URIs, and provenance. PRISM's analysis Agent receives only relevant Analysis Skills and commits a structured Analysis Result. ASCEND reasons over that result instead of scraping logs or decoding device-specific files.

4. Authority and Module Boundaries

4.1 ASCEND

ASCEND is the autonomous coordination coordinator. It owns:

• researcher conversation and objective capture;
• coordination 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;
• committed PRISM Analysis Result evaluation and decision proposals;
• next-iteration, stop, human-review, and blocked decisions;
• the global Attention Inbox, actionable requests, operator decisions, and cross-module references.

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

ASCEND is the primary researcher and operator interface. Composer, PACE, LabFlow, LabBridge, and PRISM retain module-local Web applications for development, diagnostics, and source-record inspection. Ordinary approvals, status changes, and scientific decisions must not require those applications. The deliberate exception is device-specific Human Task input, including file upload and structured instrument forms, which deep-links from ASCEND to LabBridge. Full PRISM reports may also be opened read-only when concise ASCEND evidence is insufficient for review.

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 persists ASCEND lineage supplied at job creation, publishes package-review requests through a durable outbox, accepts idempotent Attention decisions, and returns packages through its job API. It does not control coordination 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 coordination.

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 coordination

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 coordination 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 committed PRISM Analysis Result against the objective and stop conditions;
8. autonomously create the next iteration while all policy checks pass.

5.2 Coordination and iteration state

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

• coordination_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 committed PRISM Analysis Result, 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 coordination policy.

5.6 Global Attention Inbox

ASCEND is the single user-facing inbox for SDLX coordination events and actionable requests. Composer, PACE, LabFlow, LabBridge, and PRISM publish the same sdlx.attention-event/v1 envelope to:

POST /api/inbox/events
Idempotency-Key: <event_id>

The envelope identifies its source, lifecycle kind, severity, timestamp, Coordination lineage, source resource, concise presentation fields, typed domain data, and an optional action. ASCEND persists the immutable event before applying a domain projection. A duplicate event ID with identical content is acknowledged without repeating state transitions. Reusing an event ID for different content is rejected.

The Inbox stores only coordination-relevant facts:

• package ready for review or composition failure;
• loop, workflow, analysis, or Coordination lifecycle milestones;
• approval, Human Task, scientific review, or material-preparation requests;
• instrument, workflow, delivery, or analysis failures;
• evidence inconsistency and result-ready events;
• proposed next Iteration, completion, or policy stop.

High-frequency telemetry, device position streams, complete logs, artifact bytes, and module-native execution records remain in their source modules. ASCEND stores references and a user-facing projection rather than becoming a second operational database.

5.7 Action and decision contract

An actionable event contains a stable action_id, action type, allowed decisions, current state, autonomy allowance, and bounded context. The ASCEND Web renders it as a deterministic action card in the related conversation and in the global Inbox. Chat text alone never approves an operation.

The browser submits a decision only to ASCEND:

POST /api/inbox/actions/<action_id>/decisions

ASCEND records the authenticated actor and moves the action to processing before forwarding sdlx.attention-decision/v1 to the source module's common decision endpoint. Source endpoints are selected from configured, allowlisted module identities; event payloads cannot supply arbitrary callback URLs. The source remains the authority for applying the decision and returns or publishes the terminal resolved, rejected, or failed state.

An unresolved source action keeps the same action_id across delivery retries and source-service restarts. Terminal action state is monotonic: a delayed or replayed request cannot reopen an action that is already resolved, rejected, expired, or canceled. Decisions are idempotent by decision_id; conflicting reuse is rejected.

ASCEND owns the Inbox projection and decision audit. The source module owns the underlying package review, workflow approval, Human Task, or analysis review. Agent decisions are permitted only when both the Coordination policy and the action contract explicitly allow them. Human approval is the default for physical or hazardous actions.

For a Composer package, require_package_approval=false permits ASCEND to send an audited ascend-policy approval only when the action declares agent_allowed=true. When approval is required, the action is rendered at the bottom of the related ASCEND conversation. An accepted action reference satisfies the package gate for automatic continuation; the same approval is not requested a second time before PACE preparation.

5.8 Delivery reliability

Each producing module writes outbound Attention Events to a durable outbox in the same local transaction as the source lifecycle event. Dispatch uses bounded timeouts and retry with backoff. ASCEND authenticates module service identities, validates the canonical repository schema, and deduplicates by event_id.

Polling is permitted only for startup reconciliation and diagnostics. It must not create a parallel notification contract or remain the primary source of business events. P0 provides the in-product Inbox; email, enterprise chat, and external webhooks are later delivery adapters over the same persisted events.

PACE WAITING_REVIEW means a failed task was paused for incident triage; it is projected as BLOCKED in ASCEND and offers the ASCEND stage-retry workflow. It must not be presented as an approval request unless PACE publishes a concrete, actionable approval with a stable action ID. APPROVAL_REQUIRED remains an approval state.

LabFlow treats a persisted APPROVAL_REQUIRED step as a safe restart boundary: the device action has not run, locks are released, the approval cursor and stable action are restored, and execution resumes after a valid decision. A process that was interrupted after entering an ordinary device RUNNING call still fails closed because automatically replaying an unconfirmed physical command could duplicate the action. Controller idempotency and operation reconciliation are required before that boundary can be relaxed.

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 acquisition and object-store upload
  -> LabBridge output-schema validation
  -> LabFlow typed step result and references
  -> PACE pace-result-bundle/v1
  -> immutable PACE delivery archive
  -> PRISM Analysis Skills and controlled tools
  -> prism-analysis-result/v1 and analysis archive
  -> ASCEND bounded decision

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 coordination records or LLM prompts.

ASCEND consumes the committed Analysis Result. It must not load PRISM Analysis Skills, read raw PACE archives or PRISM working files, 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 coordination, 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, coordinations, iterations, automation policy, decisions, references, global Attention Inbox, action routing, launch/cancel
Composer	create and inspect package-generation jobs; package-review Attention outbox; idempotent Attention decision endpoint; return reviewed package references
PACE	register package, start/cancel/poll loop, processes, evidence, incidents, Result Bundle, delivery archive/outbox
PRISM	Analysis Runs, Analysis Skills, result/archive commitment, Attention Event outbox, replay
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 coordination 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 and immutable delivery; PRISM commits an evidence-bound Analysis Result 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. Coordination policy deterministically constrains automatic iteration count, parameter bounds, stop conditions, and approval requirements.
10. The UI exposes pending human work, coordination 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.