Writing a research report someone else can check

A supervisor reads a nine-page report claiming a strategy beats its benchmark, and the first thing she does is skip to the end looking for the section on limitations. It isn’t there. The report has a summary, some charts, a table of returns, and a conclusion — but nothing that tells her what the strategy assumes, what it was not tested against, or where it is likely to fail. She puts the report down unconvinced, not because the numbers are wrong, but because there is no way for her to check them without redoing the entire analysis herself.

This is the gap between a report that presents a result and a report that lets someone check it. The difference is not more charts or a longer conclusion. It is structure: a fixed sequence of sections that mirrors how the analysis was actually built, so a reader can follow it back to its inputs instead of taking the headline number on trust.

Why structure beats narrative

A narrative report tells the story the author wants to tell, in the order that makes the strategy look best. A structured report tells the story the analysis actually went through, in the order the work was done — universe, data, model, validation, strategy, limitations — whether or not that order is flattering. The second kind is harder to write and considerably more useful, because a reader who knows the fixed structure knows exactly where to look for the part that might be missing.

The workspace’s fixed evidence pack uses an eight-section structure for exactly this reason. Building a student or professional report around the same skeleton — even without the software producing it automatically — gives a reader the same ability to navigate straight to the part they distrust.

The eight sections, and what each one has to earn

#	Section	What it must contain	What a reader checks for
1	Universe & data	Which securities, which provider, which date range, and any known coverage gaps	Survivorship bias, provider limitations, date range long enough to matter
2	Absolute risk & return	Return, volatility, drawdown, Sharpe and Sortino for the strategy on its own	Whether the return justifies the volatility taken to get it
3	Benchmark-relative risk	Beta, tracking error, information ratio against a stated benchmark	Whether the benchmark choice is defensible, and whether “outperformance” survives its own volatility
4	Portfolio construction	Weighting method, constraints, rebalancing rule	Whether the construction method matches what the results actually simulate
5	Model	Which model, which features, which hyperparameters	Whether the model is a reasonable candidate or a black box the author cannot explain
6	Out-of-sample validation	Fold count, mean metric, standard deviation, the worst fold, embargo rows removed	Whether performance holds up out of sample or only in the average case
7	Strategy backtest	Costs, slippage, comparison against buy-and-hold	Whether the edge survives realistic frictions
8	Method & limitations	Assumptions, known weaknesses, what was not tested	Whether the author is honest about what the result does not show

Each section renders only when the underlying evidence actually exists. A report missing section 6 because no out-of-sample validation was run is not padded with a placeholder chart — the section is simply absent, which is itself informative. A reader who sees a report skip straight from the model section to the backtest section knows immediately that no out-of-sample check happened, without needing to ask.

Section 6 deserves the most attention

Of the eight sections, out-of-sample validation is where most student and early-career reports fall shortest, because it is the section most tempting to summarise with a single flattering number. A mean out-of-sample accuracy of 61% sounds like a result. It is not one — not without the standard deviation across folds and, critically, the worst fold.

Consider two hypothetical five-fold results with an identical mean:

Result	Fold 1	Fold 2	Fold 3	Fold 4	Fold 5	Mean	Worst fold
A	0.60	0.61	0.59	0.62	0.63	0.61	0.59
B	0.80	0.75	0.70	0.55	0.25	0.61	0.25

Both average to 0.61. A report that stops at the mean presents these as equally credible. A report that includes the worst fold shows that Result B collapses in one out of five out-of-sample periods — a fact any reader would want to know before relying on it, and one that changes the entire interpretation of the result. This is the single strongest argument for treating the worst fold as a headline figure rather than a footnote; the article /quantlab/validation/roc-auc-and-worst-fold works through why in more depth.

Staleness: the section that goes out of date silently

A report is rarely written in one sitting. A student drafts the model section on Monday, reruns the pipeline with a slightly different feature set on Wednesday, and finishes the report on Friday without checking whether every earlier section still reflects the Wednesday run. This is how a report ends up internally inconsistent — the universe section describes one dataset, the backtest section reflects results from a different one, and nobody notices until a reader cross-references the numbers.

The workspace’s Report Workbench addresses this with an explicit staleness state attached to every evidence block: current when the block still matches its source, stale when the source has since been rerun with different results, and unavailable when the source was never loaded in the current session. A stale block carries a visible amber note in both the on-screen workbench and any export, rather than silently keeping the old number. Refresh is a manual action — the workspace never swaps a number underneath an author without their knowledge, because a silent update is exactly as dishonest as a silently stale one, just in the other direction.

Writing a report by hand, without that mechanism, means the discipline has to come from the author: before finalising a report, check every section against the run that actually produced its numbers, not the run that happened to be open in a browser tab last.

Stating limits without undermining the work

Students in particular tend to treat a limitations section as an admission of failure and either omit it or bury it in a single vague sentence — “further research is needed.” This gets the purpose of the section backwards. A limitations section that specifically names what was not tested is what makes the rest of the report credible, because it shows the author understands the boundary of their own claim.

A useful test: could a sceptical reader think of a criticism the limitations section does not already name? If a strategy was only tested on large-cap US equities, say so in a full sentence, not a caveat. If the validation used a single chronological split rather than walk-forward folds, say so, and say what that means for how much the result can be trusted. If transaction costs were assumed at a round number rather than measured, say so. Each honestly stated limit is worth more to a reader’s trust than another paragraph of favourable interpretation.

A short checklist before submitting

Does every section have the evidence it needs, or is a section missing and unacknowledged?
Does the validation section show the worst fold, not only the mean?
Does every number in the report trace back to a run that actually produced it, with no stale figures left over from an earlier draft?
Does the limitations section name specific gaps, not a generic disclaimer?
Would a reader who disagrees with the conclusion still be able to find, in the report itself, everything they would need to check it?

That last question is the actual definition of a checkable report. It is not a report that convinces everyone. It is one that gives a reader who is not convinced everything they need to find out why, without ever having to ask the author.