UniteLabs runs need workflow-and-connector release provenance
UniteLabs documents versioned workflows linked to runs, run inputs, logs and artifacts, plus connectors with stable identity and software version. A reconstructable laboratory run still requires the exact workflow release, connector release, device state, inputs, exceptions, and outputs to be joined rather than inferred from separate records.
Editorial figure by Lab Systems Index. Source context: UniteLabs workflow versioning documentation.
Bind the automation release to the scientific run
| Object | Minimum provenance | What it does not establish |
|---|---|---|
| Workflow source | Repository, commit, branch or tag, reviewed change, author, approval, release identifier | That deployed code matches or is fit for the intended use |
| Execution environment | Runtime, packages, lockfile, container or host image, configuration, secrets reference, clock | Device readiness, method approval, or sample state |
| Device contract | Instrument identity, firmware, driver and adapter versions, command and response schema, limits | Physical action, safe state, calibration, or scientific validity |
| Run instance | Run ID, sample and container identities, method version, inputs, events, acknowledgments, exceptions | Complete execution or an approved result |
| Result and disposition | Raw and derived data links, review, deviation, rollback or rerun, final status, accountable approver | Regulatory compliance, batch disposition, or clinical conclusion |
Define the workflow release that a run can name
The direct answer is to treat laboratory automation code as a released operating artifact with more identity than a display name. UniteLabs' official documentation says workflows are deployed and versioned and each run links to a specific workflow version. Its orchestration documentation describes workflows in Git and tracked inputs, logs, and output artifacts. That engineering model supports reproducibility questions. It does not by itself establish which code, dependencies, configuration, connectors, or method a particular laboratory approved and deployed. [1] [2]
The release record should identify repository and commit, reviewed change set, branch or tag policy, package and runtime versions, dependency lock, build output or image digest, device-driver and adapter versions, configuration schema, environment, parameter defaults, test suite and data, results, unresolved defects, approver, release date, permitted use, rollback artifact, and superseded version. Secrets should be referenced through controlled identities rather than embedded in the evidence export.
Bind connector identity to the physical device and run
A connector name is not enough. UniteLabs' documentation identifies a connector by name, stable UUID, type, and connector software version. A controlled run record should also identify the instrument manufacturer and model, physical asset identifier, firmware, communication path, supported command and response versions, units, ranges, state prerequisites, timeout and retry behavior, error semantics, safe-stop behavior, and known unsupported functions. A software acknowledgment may mean accepted, queued, started, completed, or merely transmitted; the contract must define the state it actually reports. [3]
Changes in firmware, device options, network addressing, peripheral configuration, clock, calibration status, or vendor library can alter behavior without changing the high-level workflow. Detect those differences before execution and retain the observed configuration with the run. If identity or readiness evidence is missing, stop or route review according to the laboratory's approved procedure instead of selecting a plausible device or silently using a default driver.
Reconstruct the exact run and every exception
For each execution, preserve the run identifier, triggering request, workflow release, connector release, approved method or protocol reference, sample, aliquot, plate and well identities, containers, materials, controls, instrument assignments, user or service identity, start and end times, parameters and units, commands, acknowledgments, observations, raw files, transformations, derived outputs, warnings, retries, manual interventions, deviations, and downstream handoffs. UniteLabs' artifact documentation links artifacts to a run, workflow version, phase or step, and run inputs. Requested action, device-reported state, observed physical state, and scientific result remain separate. [4]
A retry can duplicate a physical action even when the first response was lost. A resumed workflow can use a sample whose temperature, volume, position, or elapsed-time condition changed during interruption. Define which steps are idempotent, which require physical verification, which may resume, and which require disposal or a new run. Preserve uncertainty and the original event sequence rather than editing the log to match the intended path.
Test release, rollback, and scientific boundaries
A buyer test should promote one reviewed workflow from a controlled development environment into a representative execution environment, verify the artifact and driver inventory, run known samples and controls, then introduce a driver mismatch, missing dependency, delayed acknowledgment, partial device action, unavailable instrument, changed configuration, manual intervention, failed output transfer, rollback, and later rerun. Reviewers should reconstruct which release acted on which physical and scientific objects.
Lab Systems Index reviewed UniteLabs' exact workflow, orchestration, connector, and artifact documentation on October 6, 2026. The records support versioned workflows linked to runs, tracked inputs, logs and output artifacts, connector identity and software version, and artifact-to-run lineage. They do not establish whether every run automatically persists the exact connector release and physical-device state used. They also do not establish code quality, device behavior, sample custody, method execution, result validity, validation status, data integrity, safe operation, regulatory suitability, or laboratory outcome. [1] [2] [3] [4]
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Lab Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.