Writing a technical report

A technical report has one job: to let another person understand, judge and repeat what you did. The structure:

1. The summary (5 sentences): the problem, the method, the main result with a figure and its uncertainty, a limitation.
2. The problem and the hypothesis: what, why, what would falsify it.
3. The method: the data (the source, the size, the split, the licence), the model, the training, the evaluation, the baselines — enough to repeat it.
4. The results: tables with the mean ± the spread, CIs; figures with axes from zero where that is reasonable; no interpretations here.
5. The analysis: the ablations, the error analysis, what surprised you.
6. The limitations: honestly — the data, the generalisation, the cost, what you did not test.
7. Reproducibility: the commit, the data hash, the configuration, the seeds, the hardware, the time.

The language: «our method improves the F1 by 2.1 pp [0.4; 3.8] on test set X» — not «our method is considerably better». Every adjective without a number behind it is deleted.

Rewrite these:

Before	After
«The model performs very well.»	«Macro F1 0.84 [0.81; 0.87] on 600 test cases, against the TF-IDF baseline's 0.77 [0.74; 0.80].»
«We tested many settings.»	«We searched lr ∈ {1e-5, 2e-5, 5e-5} and epochs ∈ {2, 3, 5} on the validation data, equally for the baseline and the model (table 3).»
«The results probably generalise.»	«We have only tested on Swedish support cases from one organisation; generalisation to other domains is untested.»

A checklist before handing in: every figure has an uncertainty · every table has an n · the baseline is described as carefully as the method · the limitations are concrete · the commit and the data hash are included · somebody who was not involved can follow the method.