1. The decision question
Open with one sentence stating the behaviour or claim being verified. It should be precise enough that a supported, contradicted or undefined result is possible.
2. Scope and exclusions
Record the software version, component, environment, inputs and workflow included. Name material exclusions so nobody silently treats a focused result as whole-product approval.
3. Acceptance conditions
Describe what observation would count as success or failure before presenting the result. This separates the evidence from hindsight.
4. Checks performed
List the relevant tests, reproductions or comparisons in a form another person can understand. Link commands, logs or code references where sharing is possible.
5. Observations and evidence
State what occurred. Keep observation separate from interpretation. Screenshots can help, but text logs, repeatable steps and versioned code generally provide stronger inspection paths.
6. Result and confidence boundary
Say whether the evidence supports the claim, contradicts it or remains insufficient. Explain why and tie the result back to the agreed conditions.
7. Practical next action
Close with the smallest useful action: release the bounded change, correct the identified issue, gather missing evidence, expand the scope or escalate to a specialist assurance process.
A concise report can still be rigorous
Length is not the measure of quality. A short finding with inspectable evidence and explicit limits is often more useful than a long document that hides the decision. Spotted Ridge reports use a condensed result with expandable technical detail where the evidence requires it.
See our public evidence or review the available verification scopes and prices.