Golden Loop Verification and Next Delivery

Purpose

The Golden Loop is SDLX's minimum repeatable scientific execution path:

ASCEND Campaign Iteration
  -> Composer-reviewed PACE package
  -> PACE loop run
  -> LabFlow workflow run
  -> LabBridge operation
  -> controller or Human Task
  -> structured parameters and artifact URIs
  -> pace-result-bundle/v1
  -> ASCEND evidence-based decision

This path is the acceptance line for new modules, physical controllers, result contracts, and autonomous campaign behavior. A feature is not considered part of the scientific loop merely because its individual API works.

Current Baseline

The deterministic software path is implemented. The repository currently contains two end-to-end exemplars:

1. Powder preparation, heating, operator-assisted XRD upload, deterministic phase analysis, and archival.
2. Operator-assisted RDE cell preparation followed by automated ORR linear sweep voltammetry and semantic result extraction.

Both paths use the same operation contract for simulated, physical, and operator-assisted devices. Workflows do not branch on simulation state.

Acceptance Criteria

A Golden Loop package must prove all of the following:

1. PACE stores an immutable package snapshot and package hash.
2. Composer-selected workflow modules pass deterministic validation and capability binding.
3. LabFlow creates a durable run, executes a DAG, and preserves step state.
4. LabBridge returns terminal operations with output-schema-validated results.
5. Device controllers return compact semantic values or object-store artifact URIs instead of device-native blobs.
6. Human Tasks preserve schema, sample, revision, artifact role, checksum, operator identity, rejection, and resubmission history.
7. PACE extracts declared result paths into facts, measurements, observations, evidence, incidents, and a versioned Result Bundle.
8. Missing required results produce INCOMPLETE, an incident, or a TODO rather than a false success.
9. ASCEND reads committed evidence, checks campaign policy, and records one structured next-round, stop, human-request, or blocked proposal.
10. Cancel, rejection, process restart, and external waits remain diagnosable and recoverable.

Verification Layers

Contract Tests

Module-local tests validate schemas, state transitions, authorization, idempotency, result extraction, and error behavior.

scripts/test-golden-loop-recovery.sh

This suite covers Human Task rejection and resubmission, operation-terminal waits, cancellation forwarding, spatial resources, and ASCEND campaign records.

Live Process Recovery

The live suite uses isolated ports and temporary databases. It starts real LabBridge workers, LabFlow, PACE, and ASCEND; writes persistent records; sends SIGKILL; restarts the services; and verifies the same records over HTTP.

scripts/test-live-process-recovery.sh

The same command is registered in .github/workflows/recovery.yml.

Physical Acceptance

A physical-device acceptance run must additionally prove:

• controller command idempotency;
• safe reconciliation after an uncertain timeout;
• controller-reported robot, carrier, and docking state;
• calibrated station and service-port identity;
• artifact upload durability and checksum verification;
• safe-stop behavior that matches the device's real failure modes.

Stable Contracts

The following boundaries should evolve through versioned schema changes rather than ad hoc payload extensions:

• Composer: POST /api/composer/jobs and immutable package output.
• PACE: package schema v2, task types, result contracts, Result Bundle v1, and process table.
• LabFlow: workflow schema, run export, operation references, external waits, spatial lease requests, and cancellation.
• LabBridge: capability input/output schemas, operation terminal results, artifact metadata, Human Tasks, stations, leases, and carrier custody.
• ASCEND: Campaign, Iteration, decision proposal, automation policy, and external reference records.

Next Delivery Priorities

1. Implement idempotent physical controller adapters for selected instruments and mobile robots.
2. Calibrate the first real map revision, stations, service ports, and reviewed mobile-manipulator modes.
3. Run the two Golden Loop exemplars against mixed simulated and physical fleets without changing package logic.
4. Connect trusted-proxy identity to the deployment identity provider.
5. Enable public documentation TLS routing and monitor the recovery workflow in the remote CI environment.