Study vs Sequencing Order Pipelines

SeqDesk supports two pipeline scopes. Both use packaged Nextflow workflows, but they start from different places in the product and write different kinds of results back into SeqDesk.

At a Glance

Scope	Start from	Typical input	Typical output	Current examples
Study pipeline	A study	Selected study samples and their assigned reads	Assemblies, bins, reports, submissions	MAG, SubMG, Reads QC
Sequencing Order pipeline	A sequencing order	Sequencing order samples and their linked sequencing files	Read-level QC, checksum validation, synthetic reads, cleaned-read candidates, run artifacts	Simulate Reads, FASTQ Checksum, FastQC, Read Cleaning

(MetaxPath is an optional/external study package, not part of the built-in catalog — see Available Pipelines.)

Study Pipelines

Study pipelines run across a whole study and combine multiple samples for larger analysis, reporting, or submission workflows.

Typical characteristics:

Started from the Pipelines area of a study
Work on the selected study samples together
Produce higher-level outputs such as assemblies, MAGs, reports, or archive submissions
Store results in study-linked models such as Assembly, Bin, and run artifacts

Use a study pipeline when you want to analyze a dataset as a study-wide unit, for example with MAG assembly/binning, pathogen profiling, or ENA submission.

Sequencing Order Pipelines

Sequencing Order pipelines run on the individual samples and linked sequencing files of a sequencing order. They are designed for operational sequencing tasks such as validation, quality control, and preparation of FASTQ data before or alongside downstream analysis.

Typical characteristics:

Started from a sequencing order context
Operate on per-sample linked reads inside that sequencing order
Produce run artifacts and safe writeback updates on canonical Read records
Are narrow and composable, so multiple sequencing order pipelines can be run on the same sequencing order

Today, SeqDesk includes four sequencing order pipelines:

Simulate Reads

Generates dummy FASTQ files for sequencing order samples. This is useful for demos, local validation, and smoke-test scenarios where you want realistic files to exist before downstream QC or checksum steps run.

Writeback to Read:

file1
file2
readCount1
readCount2

FASTQ Checksum

Computes MD5 checksums for linked FASTQ files and stores them on the canonical read record. These values are then available for validation and submission workflows.

Writeback to Read:

checksum1
checksum2

FastQC

Runs per-sample FastQC on linked sequencing order reads, stores report paths, and extracts selected summary metrics for direct use in SeqDesk.

Writeback to Read:

fastqcReport1
fastqcReport2
readCount1
readCount2
avgQuality1
avgQuality2

Read Cleaning

Screens raw/unknown sequencing order reads for host/contaminant sequences via nf-core/detaxizer and stages cleaned FASTQ files as candidates. Unlike the pipelines above, it does not write directly to active Read records: cleaned candidates are stored as run artifacts and only become active reads after an admin promotes them through the pending-writebacks review flow. Raw and unknown source reads are preserved. Admin-only by default.

A Common Sequencing Order Workflow

One practical pattern is to chain the current sequencing order pipelines:

Run Simulate Reads to generate or refresh FASTQ files for the sequencing order.
Run FASTQ Checksum to populate canonical checksums.
Run FastQC to publish QC reports and extract read-level quality metrics.

This keeps the workflow modular while still writing the important results back to the same canonical Read rows used elsewhere in SeqDesk.

How Sequencing Order Pipelines Are Packaged

Sequencing Order pipelines use the same package system as study pipelines. Each package contains:

manifest.json for runtime scope, execution, inputs, outputs, and writeback
registry.json for presentation metadata and configuration schema
samplesheet.yaml for generated Nextflow input files
optional discovery scripts for matching produced files back to samples or reads

The runtime contract is manifest-first. In practice this means:

targets.supported defines whether a package is meant for study, order, or both
inputs[].source declares which SeqDesk data the package reads
outputs[].writeback declares which discovered metadata keys may update canonical Read fields
SeqDesk still performs the actual database write centrally after validating the manifest contract

Shortened example:


{
  "targets": {
    "supported": ["order"]
  },
  "inputs": [
    {
      "id": "reads",
      "scope": "sample",
      "source": "sample.reads",
      "required": true
    }
  ],
  "outputs": [
    {
      "id": "sample_checksums",
      "scope": "sample",
      "destination": "sample_reads",
      "writeback": {
        "target": "Read",
        "mode": "merge",
        "fields": {
          "checksum1": "checksum1",
          "checksum2": "checksum2"
        }
      }
    }
  ]
}

Catalog and Installation

The public pipeline catalog and the in-app install UI group packages by scope using this manifest metadata. That keeps the user-facing experience unchanged while making sequencing order pipelines easier to discover and maintain separately from study pipelines.

For more detail, see: