Overview

Use this page as the reader briefing. It explains what fq-compressor is trying to prove, which audiences the documentation serves, and how the rest of the site should be read.

What this portal is for

• Present fq-compressor as a system design for FASTQ compression, not only as a benchmark result.
• Give interviewers and advanced developers a short route into architecture, evidence, and source anchors.
• Keep operators and contributors from being forced through the full whitepaper before they can act.

Reading order

1. Read Whitepaper for the central thesis and major design claims.
2. Read Architecture for module boundaries, pipeline flow, and format responsibilities.
3. Read Benchmarks for the evidence boundary and method.
4. Read Academy if your question is operational.
5. Read Research if your question is comparative, historical, or bibliographic.

Who each lane is for

• Interview loop: Whitepaper, then Benchmarks.
• Advanced GitHub readers: Architecture, then Research.
• Operators: Academy, with Architecture open beside it when an option needs deeper context.
• Contributors: Architecture, Academy, and repository anchors referenced from Research.

Why this structure exists

This site is meant to make claims auditable. If a statement about fq-compressor cannot be connected to architecture, measurement method, or tracked repository artifacts, it should not be treated as part of the durable public story.