Skip to content

Lab_Automation_MolBio_and_Sequencing.md

Latest commit

 

History

History
177 lines (133 loc) · 6.71 KB

Lab_Automation_MolBio_and_Sequencing.md

File metadata and controls

177 lines (133 loc) · 6.71 KB
Raw

Lab Automation, Mol Bio, and Sequencing

BioModStack is not limited to protein-design workflows. The live UI and API also expose sequence operations, nanopore analysis, and the BioXP compact control plane.

Molecular Biology Toolkit

Frontend route:

  • /designer

Primary component:

Current surface includes:

  • DNA and RNA construct viewing/editing
  • sequence shelf / construct library
  • construct import and paste flows
  • feature and primer editing
  • digest planning
  • PCR product generation
  • search/find utilities
  • direct sequence edit operations
  • GC-content and annotation-oriented sequence visualization

The mol bio API surface is split across:

  • /api/sequences saved nucleotide constructs
  • /api/molbio digest, PCR, ligation, mutagenesis, Gibson, and Golden Gate operations
  • /api/user-sequences user sequence library helpers
  • /api/user-templates reusable sequence/template assets

Nanopore / NGS Surface

Frontend route:

  • /ngs

Primary components:

The current sequencing surface is oriented around Oxford Nanopore workflows.

Supported input patterns:

  • POD5 input for Dorado basecalling
  • existing BAM input for methylation/reporting workflows
  • FASTQ input for alignment and QC against a reference

Current sequencing features:

  • Dorado basecalling
  • optional Dorado alignment
  • BAM normalization/preparation for downstream analysis
  • modkit methylation summary outputs
  • FASTQ plasmid QC
  • IGV-ready track and reference artifacts
  • optional clone-validation style workflow handoff parameters

Sequencing model configuration:

The workflow logic lives in:

ONT Read and Signal Workbench

The /ngs result surface includes the Read and Signal Workbench for one persisted run generation. It uses IGV to view alignments and can show:

  • one acquired-signal waveform from the selected run’s retained, indexed BLOW5 file;
  • reusable signal-to-read and signal-to-reference mappings;
  • read, reference, and pileup views within configured limits, rendered by a pinned Squigualiser version without network access; and
  • saved viewer state that reopens the same read, locus, mapping, and render job.

Acquired signal remains authoritative only when it resolves through the exact run, generation, raw representation, retained partition, and index. Derived plots and simulated artifacts never satisfy an instrument raw-signal lookup. Historical metadata with missing device/profile evidence remains legacy_unknown; it is not silently relabeled compatible.

The source tree contains the gated Squigulator ideal-reference comparison lane and manual trace-review ledger. Squigulator output is explicitly model-derived—not acquired signal—and uses a runtime identity separate from the Squigualiser comparison renderer. This lane must not be described as a live operator capability until both OCI identities, bounded execution, visible synchronized tracks, and artifact/review behavior pass live acceptance in the Development service.

BioXP Robotics Surface

Frontend route:

  • /bioxp

Primary frontend client:

Primary backend router:

Canonical current contract:

This is a BMS-linked cockpit for a robot-local BioXP runtime, not a generic cloud API and not a shell-based daemon supervisor.

Current capabilities include:

  • explicit profile save/forget with masked readback
  • process-local connect, disconnect, and bounded readiness probe
  • orthogonal configured/active/reachable/runtime/hardware/freshness evidence
  • robot-owned operator catalog, admission, invocation, and durable receipts
  • canonical activation and recovery through meta.activate_motion and meta.recover_motion_non_homing
  • physical aggregate emergency stop through the robot operator plane
  • deterministic offline protocol validation
  • persistent local jobs with append-only transition events

Current operational caveats:

  • BMS is a typed presentation and connection layer, not an arbitrary robot proxy or a second BioXP command authority.
  • Production BioXP linkage is intentionally disabled; current work uses the Development test environment and selected robot runtime only.
  • Stale or unknown connection/ownership generations never authorize a mutation. The robot decides action readiness and admission.
  • Offline protocol validation does not claim robot compatibility or executability.
  • Repeated camera/UVC control-query failures and the historical Novo USB/CAN reset pattern should be documented as unresolved transport/recovery instability. Software reconnect/reset behavior remains a major confounder, so the current docs do not treat this as a closed "bad componentry" or blanket hardware-failure verdict.

Runtime dependencies:

  • network reachability from BMS to the explicitly saved robot-local BioXP profile
  • a robot-local BioXP runtime supervised outside BMS (for example bioxp-api.service)
  • an allowlisted host/CIDR before enabling robot-facing mutations

Important env vars:

  • BMS_BIOXP_MUTATIONS_ENABLED defaults to 0; robot-facing commands remain unavailable until explicitly enabled
  • BMS_BIOXP_ALLOWED_HOSTS / BMS_BIOXP_ALLOWED_CIDRS explicit target allowlists used when validating the saved profile

Normal operation does not use BMS to start, stop, reset, reboot, shell into, or collect remote logs from the robot host. Those routes are absent; use the robot-local service/runbook instead.

Workstation / System Operations

BMS also exposes workstation-facing support surfaces outside the structure workflows:

  • /infra system telemetry and power/fan controls
  • start_ui.sh API/frontend launcher
  • biomodstack_panel.py GTK control panel for local service operation

What These Docs Deliberately Avoid

These docs describe the live surfaces. They do not treat every robotics or sequencing idea note in docs/ as current support. If a behavior matters for a run or operator flow, confirm it in the active frontend route, API router, or workflow entrypoint referenced above.