Evolution notes
FastQTools did not arrive at its current documentation and architecture shape by accident. The maintained system story is the result of several decisions that turned implementation concerns into explicit public reasoning material.
RFC spine
RFC-0001 established the layered architecture, the zero-copy batch model, and the `source → processing → sink` execution path. RFC-0003, RFC-0004, and RFC-0006 then deepened benchmark governance, memory policy, and publication discipline.Core architecture became the stable spine
RFC-0001 matters beyond code organization: it made it possible for the CLI, API, and benchmark story to reuse the same systems frame.
Memory policy moved into first-class design language
RFC-0004 made memory reuse and in-flight bounding explicit instead of treating allocation behavior as an implementation footnote. Once record views depend on batch lifetime, memory policy becomes part of correctness, not only part of optimization.
Benchmark publication became governed, not anecdotal
RFC-0003 defined how benchmark data is collected and stored. RFC-0006 then separated release-facing SLA language from informational GitHub Pages benchmark publication. Together they changed performance from “interesting numbers” into maintained evidence.
Documentation now mirrors that engineering split
The current docs separate narrative, operational, and research responsibilities:
Whitepapercarries product scope and review framing.ArchitectureandAlgorithmscarry system and execution reasoning.Performancecarries evidence interpretation.Referencecarries exact lookup material.Research appendixcarries bibliography, comparison context, and historical notes.
What should remain stable
Even if the project grows, the key discipline should remain the same: new capabilities should not collapse narrative, implementation, evidence, and reference material back into one undifferentiated landing page. The current structure works because each layer answers a different question with a different level of proof.