BTGenZComputational PCR pipeline development and scientific validation
The infrastructure has been developed and tested over approximately six months, with more than 900 tests reported during development. This page explains what that figure covers, what a complete acceptance run demonstrates, and what none of it claims.
Different kinds of testing show different things
Passing software tests shows that the code does what it was written to do. It does not show that a method is scientifically right for a given sample. The table separates the types of testing and shows what evidence each has on this site.
| Type of testing | What it checks | Evidence on this site |
|---|---|---|
| Software functionality testing | Individual functions and modules behave as specified. | Included in the 900+ tests reported. Not itemised here. |
| Integration testing | Modules exchange data correctly and in the right order. | Acceptance run: eleven workflows coordinated in a single project. |
| Workflow execution testing | A full workflow runs from input to deliverables without interruption. | Acceptance run: 11 of 11 workflows executed to completion. |
| Scientific consistency checks | Results obey expected relationships, such as a ladder calibration that fits well. | Examples appear in the example outputs, such as the gel ladder fit (R² = 0.9913). |
| Benchmark testing | Outputs are compared with reference values or established tools. | Not itemised on this site. |
| Input validation | Files and parameters are checked before analysis starts. | Acceptance run: 50 of 50 files validated with a detected format and role. |
| Output verification | Deliverables are complete and have not changed since they were written. | 173 output artifacts listed with SHA-256 checksums. |
The acceptance run
The clearest single piece of evidence is a full-mode acceptance project built from synthetic test fixtures: reference sequences, primers, SNP alleles, a multiplex panel, qPCR transcripts, target regions, paired-end reads, a Ct export, a gel image, a Sanger trace and digital PCR amplitudes. Because the data are synthetic, the project tests how the platform behaves, not whether a biological conclusion is right.
Intake
50 files were ingested across 11 detected formats, and all 50 passed validation with an assigned role.
Coordination
The assessment selected all eleven workflows, found no blocking missing input, recorded the dependency between gel analysis and conventional PCR design, and set the execution order.
Execution
All eleven workflows ran to completion and produced reports, workbooks, machine-readable results and figures.
Traceability
173 output artifacts are listed with format, module and SHA-256 checksum. A hash-linked audit trail records module events in order.
Reproducibility
Software versions are recorded with the run, including primer3-py 2.4.0, BLAST+ 2.17.0 and Biopython 1.88.
Scale of use
The research workspace dashboard lists 896 project records, 890 of them completed, at the time of capture. Many carry test names. See the technical showcase.
Scientific QC is not the same as successful execution
A program can run without error and still produce a result that should not be relied on. In this platform every module reports two separate things: an execution status, which says whether the analysis ran, and a scientific QC outcome, which says whether the result meets the scientific criteria for that analysis.
Execution status
Completed, or not. A completed status means the files were read, the calculations finished and the deliverables were written.
Scientific QC outcome
Pass, pass with warnings, or fail, judged against thresholds specific to the analysis: thermodynamic criteria for primers, coverage and quality for sequencing reads, replicate precision for qPCR, and so on.
In the acceptance run every workflow completed, while the scientific QC outcomes differed between modules and included pass, pass with warnings and fail results. That spread is the intended behaviour of a QC gate. If every module always reported a pass, the gate would not be telling anyone anything.
What this page does not claim
- It does not claim independent experimental validation of any workflow.
- It does not claim clinical validity, regulatory approval or guaranteed experimental outcomes.
- It does not present synthetic acceptance outputs as biological findings.
- It does not itemise the 900+ tests or report benchmark comparisons.
Customer data would be analysed under the same QC gates, and the report for each module states its limitations alongside the result.
Next step
The next page describes the engineering and scientific problems met while building the system.