A report is not improved by converting every tool screen into a screenshot. It is improved when a reviewer can follow the reasoning from instruction to evidence to conclusion.
Start with the instruction
The report should state what the examiner was asked to do, the evidence received, relevant dates, agreed exclusions and any later change in scope. Without that frame, even correct technical observations can be used for a question they were never meant to answer.
Separate four layers
- Method: what the examiner did and under which conditions.
- Observation: what the available artifact or record shows.
- Interpretation: what the observation may mean in context.
- Limitation: what is missing, ambiguous or not supported.
Consider a location record. The observation may be a timestamp and coordinate stored by an application. The interpretation may be that an account or device was associated with that location. Whether it proves a person’s presence is a different and often unsupported proposition.
Keep source references alive
Material findings should link to stable source references: artifact identifiers, paths, record keys, timestamps, report bookmarks or exported exhibits. If a finding cannot be checked without rerunning an opaque tool view, independent review becomes harder.
Make limitations specific
Generic language such as “tools may have limitations” adds little. A useful limitation identifies the affected source or conclusion:
- an application database was inaccessible;
- deleted records could not be established;
- a timestamp had ambiguous timezone treatment;
- the available export covered only part of the relevant period;
- an interpretation depends on account attribution not independently verified.
Write for two readers
Decision-makers need a clear summary. Technical reviewers need enough detail to reproduce or challenge the work. A concise main report with a method and artifact appendix can serve both without confusing volume with rigour.
Use the report-reading notes or discuss reporting and review.