Whitepaper

Review the technical whitepaper before making adoption claims.

The whitepaper section frames why FastQTools exists, what constraints shaped it, and how the evidence should be read.

Open whitepaper

Positioning

Start with why FastQTools

Understand the product boundary, intended use, and the specific problems the project is trying to solve.

Read positioning

Architecture

Trace the design rationale

Review the architectural decisions that support zero-copy IO, constrained workflows, and maintainable quality controls.

Read architecture

Evidence

Validate the performance story

Read benchmark-backed claims before repeating them in adoption documents or technical reviews.

Review performance

Whitepaper

System overview

FastQTools is easiest to evaluate when you treat it as a deliberately narrow FASTQ quality-control engine. The maintained surface does not promise an all-purpose sequencing platform. It promises a disciplined stat and filter workflow, a reusable C++ integration layer, and the execution policies needed to make those surfaces explainable under review.

Review questions

The whitepaper layer exists so an adopter can answer three questions before opening the source tree:

1. What boundary is actually maintained? FastQTools claims statistics, filtering, trimming, gzip-aware I/O, and bounded execution policy for FASTQ QC; it does not claim to replace arbitrary downstream bioinformatics stages.
2. What systems model explains the performance posture? Throughput claims are tied to zero-copy record views, bounded FastqBatch ownership, and oneTBB stage orchestration instead of vague “C++ is fast” language.
3. Where does the proof trail live? Architecture RFCs, benchmark policy, research references, and implementation reference pages remain visible so every headline claim can be audited later.

What this layer is trying to prove

The point of this chapter is not to restate the README in longer form. It is to establish a review posture: read FastQTools as a bounded system with explicit contracts, explicit non-goals, and explicit follow-on chapters for architecture, algorithms, performance, and reference work.

The primary boundary documents behind this page are Product Spec, RFC-0001, and RFC-0006.

Boundary contract

FastQTools is strongest in the part of the sequencing workflow where teams need a repeatable QC and preprocessing core before heavier downstream stages begin. That means:

• it is in scope to discuss summary statistics, per-position metrics, supported filtering predicates, supported trimming mutators, gzip input/output handling, and the execution controls that keep throughput and memory bounded;
• it is out of scope to describe FastQTools as a workflow platform, classifier, mapper, or umbrella for unrelated sequencing stages;
• it is valid to compare the project with adjacent QC tools, but only when the comparison stays anchored to current capabilities instead of imagined roadmap features.

That distinction matters because the whitepaper is closer to a technical due-diligence packet than to a product-marketing landing page.

Claim discipline matrix

Claim class	What the site may say	Where to verify
Product boundary	FastQTools maintains stat, filter, gzip-aware FASTQ I/O, bounded predicates, bounded mutators, and a reusable C++ surface.	Product spec and API pages
Execution model	Throughput is explained through contiguous batch ownership, std::string_view record views, staged execution, and oneTBB orchestration.	Architecture and algorithms chapters
Evidence posture	Published numbers are representative benchmark evidence with conditions, not portable guarantees for every machine or dataset.	Performance chapter and benchmark RFCs
Research context	Adjacent tools are comparison anchors for scope and evidence style, not targets to subsume.	Research appendix and bibliography

This matrix is intentionally conservative. It keeps the documentation from drifting into unreviewable claims while still giving senior readers enough material to evaluate design quality, operational fit, and comparison context.

Reading path

This page leads into the deeper whitepaper layers in the same order a technical review usually happens.

Reading itinerary

Read the next layers in the same order you would review a system during technical evaluation:

1. Architecture — inspect the boundary ledger, control surfaces, and failure-containment decisions.
2. Algorithms — inspect how filtering, statistics, execution policy, and memory discipline translate the architecture into maintained behavior.
3. Performance — read the benchmark envelope together with methodology, caveats, and reproduction trail.
4. Research appendix — collect bibliography, adjacent-project context, and evolution notes once the main claims are already clear.

If you are still deciding whether FastQTools belongs in your environment, it also helps to read Why FastQTools before going deeper and Reference once you need concrete commands, APIs, or implementation material.

Reading order through the deep-content layers

The itinerary above is deliberate: narrative framing comes first, systems reasoning comes second, performance interpretation comes third, and operational lookup only appears once the reviewer already understands what is being operated.

Reviewer handoff

After the first pass, the strongest route is to read this site as a dossier:

1. collect the maintained scope from this page;
2. inspect the system boundary in Architecture;
3. inspect behavior and invariants in Algorithms;
4. interpret the benchmark envelope in Performance;
5. use Research appendix only after the main system story is clear enough to cite or compare.

Core internal references

Internal documentation anchors

These entries come from the site-wide reference catalog created in the IA foundation. Use them as the canonical internal reading trail before you jump to external context.

1. DocWhitepaper overview

   Primary narrative entry that ties positioning, architecture, and evidence together.

   Theme concept: whitepaper

2. DocArchitecture rationale

   Trace zero-copy I/O, parallel pipelines, and maintainable boundaries.

   Theme concept: architecture

3. DocAlgorithm and workflow entry

   Keeps learning paths, workflows, and execution pages in one navigation skeleton.

   Theme concept: algorithms

4. DocBenchmark methodology

   Explains environment, caveats, and how to read throughput numbers.

   Theme concept: performance

5. DocReference hub

   Shared entry for CLI, API, build, and testing material.

   Theme concept: referenceNav

6. DocResearch appendix

   Collects bibliography, adjacent-project comparison, and design evolution history.

   Theme concept: researchNav