Study vs 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, MetaxPath, SubMG
Order pipeline	An order	Order samples and their linked sequencing files	Read-level QC, checksum validation, synthetic reads, run artifacts	Simulate Reads, FASTQ Checksum, FastQC

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.

Order Pipelines

Order pipelines run on the individual samples and linked sequencing files of an 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 an order context
Operate on per-sample linked reads inside that order
Produce run artifacts and safe writeback updates on canonical Read records
Are narrow and composable, so multiple order pipelines can be run on the same order

Today, SeqDesk includes three order pipelines:

Simulate Reads

Generates dummy FASTQ files for 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 order reads, stores report paths, and extracts selected summary metrics for direct use in SeqDesk.

Writeback to Read:

fastqcReport1
fastqcReport2
readCount1
readCount2
avgQuality1
avgQuality2

A Common Order Workflow

One practical pattern is to chain the current order pipelines:

Run Simulate Reads to generate or refresh FASTQ files for the 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 Order Pipelines Are Packaged

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 order pipelines easier to discover and maintain separately from study pipelines.

For more detail, see: