⟨System Name⟩ — Technical Report

Project ⟨Pnn⟩ · ⟨weeks⟩ · ⟨date⟩ · repository: ⟨url⟩

1,500–4,000 words for a project report. 6,000–10,000 for P15's paper. Sections marked required are scored by the scorecard and may not be empty.

Abstract

⟨150 words. What you built, what you measured, what you found — including the number. An abstract without a number is a description.⟩

1. Problem and Motivation

⟨What problem does this system solve? Why does the naive approach fail? Quantify the failure — at what scale, by how much.⟩

2. Background and Related Systems

⟨What already exists, and how your design relates. Short. This is not a survey.⟩

3. My Initial Design — required

⟨The design you wrote before reading the literature, and its reasoning. Then: where it was wrong, and what the canonical design does differently and why.

This section is what makes the report yours rather than a re-description. Keep it even when — especially when — your design was wrong.⟩

4. Architecture

⟨Components, data flow, key data structures. One diagram. State the design decisions that were genuinely decisions, with the alternative you rejected and why.⟩

5. Implementation Notes

⟨What was harder than expected. Which bug took longest and what it taught you. Language and library choices with reasons. Lines of code by component, if informative.⟩

6. Correctness

⟨How you know it works. Property tests, invariants, model-based testing, fuzzing. What each class of test caught. Known limitations and unverified assumptions.⟩

7. Methodology — required

⟨Hardware, software versions, workload generation, measurement method, statistics. Enough that the numbers in section 8 can be interpreted and challenged.

State explicitly: how many runs, how variance was estimated, what warmup was done, and what the machine was doing at the time.⟩

8. Baselines

⟨What you compare against and why it is fair. Include a degenerate configuration of your own system wherever possible.⟩

9. Results

⟨Tables and figures. Every latency as p50/p95/p99. Every claim with its uncertainty. Units on everything. Sample size on everything.⟩

10. Analysis

⟨Where does the time go? What is the bottleneck, and is it computational, algorithmic, architectural, or operational? Decompose ratios into their factors rather than reporting them whole.⟩

11. Hypothesis and Experiment — required

⟨The falsifiable claim, its stated falsifier, the controlled experiment, and the outcome. Whether it survived or not.⟩

12. Ablations

⟨What happens when each component is removed. If removing a component changes nothing, say so — it means the component is not part of the mechanism.⟩

13. What I Expected And Did Not Get — required

⟨Every prediction that was wrong, the size of the gap, and the mechanism behind it. Negative results, failed approaches, and things that turned out not to matter.

This section may not be empty. If it is, the predictions were too safe or they were written after the results.⟩

14. Failure Behaviour

⟨What breaks it. What it does under fault injection, overload, skew, and adversarial input. What degrades gracefully and what does not.⟩

15. Limitations and Threats to Validity — required

⟨What this work does not show. Where the measurements might mislead. Which conclusions depend on an assumption you did not verify. Scale you did not test.⟩

16. Future Work

⟨The extensions you scoped out, and the one experiment you most want to run next.⟩

17. Reproducibility — required

repository :
commit     :
setup      :  <one command>
test       :  <one command>
benchmark  :  <one command>
runtime    :
hardware   :
expect     :  <headline number ± tolerance>

⟨Verify this by following it yourself from a clean clone before publishing.⟩

References

⟨Primary sources. Papers, books, official documentation, source code you read.⟩

Self-Assessment

⟨Scorecard, twelve categories, 1–5, with the evidence for each score named. Score down when unsure.⟩