Integrated PCR analysis workflow architecture

The platform is organised around how a PCR project actually unfolds: intake and validation, a decision about which analyses apply, the analyses themselves, a scientific quality check, and one consolidated record. Each stage is described below without exposing source code or internal configuration.

Select any module in the diagram to open its description. The dashed line marks the one stated dependency between an analysis workflow and a design workflow.

1. Project intake and sequence validation

A project starts with whatever files the researcher has. In the acceptance project that meant 50 files in 11 detected formats: FASTA, FASTQ, BED, region tables, SNP definitions, primer tables, qPCR exports, a gel image, an SCF trace, digital PCR amplitude exports and parameter documents. Files are recognised by content rather than by name, given a role (for example reference sequence, forward read, ladder image) and recorded with a SHA-256 checksum. All 50 files in the acceptance project passed validation.

Sequences are then validated and normalised before any design work starts, so every later module reads the same cleaned template.

2. Workflow assessment and target identification

The assessment step reads the objective and the assigned files and produces a plan: which workflows apply, the reason each was selected, which input files each needs, any required input that is missing, the dependencies between workflows, and the order of execution. It also records the stated scientific limitation of each workflow, for example that qPCR relative quantification needs a designated control sample and reference gene.

For the acceptance project the plan selected all eleven workflows, found no blocking missing input and ordered the design workflows ahead of the data-analysis workflows.

3. Design and data-analysis modules

Standalone use and coordinated use

Every module keeps its own orchestration, parameters, report and outputs, so it can be run by itself on a single dataset. In a coordinated project the same modules are sequenced by the workflow assessment, share the validated inputs, and contribute to one consolidated summary. Nothing about a module's scientific logic changes between the two modes.

4. Scientific quality assessment

Each module ends with its own scientific QC gate. This is deliberately separate from execution status. A module can run to completion and still report a scientific QC concern, such as low coverage, a replicate outside tolerance or a primer pair that fails a thermodynamic criterion. Reports keep the two fields apart so that a successful run is never mistaken for a successful result. The validation page explains the distinction.

5. Reporting and consolidated deliverables

Each module produces a scientific PDF report, an Excel workbook, machine-readable JSON and annotated figures. A project-level summary consolidates the workflows in one document. The acceptance project recorded 173 output artifacts, each listed in a manifest with its format, module and SHA-256 checksum, and a hash-linked audit trail records module events in order. Software versions are written with every run.

Established components

These are third-party open-source components used by the platform. BTGenZ does not claim to have developed them.