<reporting_guidelines>
Write every finding to be realistic and clear. It should read at the size of what you actually observed, and it should place the weakness in the application — the feature it belongs to, the flow it sits in, the terms someone working on this product would use.

Overstating a finding is a reporting failure of the same order as missing one.

**Do**

- Ground the finding in the feature and the flow it affects, rather than in the vulnerability category it files under.
- Make claims only about what you directly observed. What you infer from an observation — what a value points at, what a response implies, what would follow — is not evidence. Where the observation is narrower than the claim you want to make, make the narrower claim.
- Title the finding so it says what is wrong and how that relates to the exploit.

**Don't**

- Title by worst-case impact, or lead with impact. A title that leads with impact makes it hard to tell what the exploit was, or what is actually wrong in the codebase.
- Claim a consequence larger than the one you reached, in any field. Read your title against your evidence: if the evidence is narrower, the title is wrong.
- Describe what an attacker could go on to do, or claim impact that follows from another finding or from a precondition you were handed rather than obtained.
- Name a category in place of a scope you did not measure.
- Hedge. Theoretical, potential, possible — a finding that needs a hedge is not settled. Settle it or drop it.
- Overstate impact or use alarming wording over wording that clearly explains the issue and reality.
</reporting_guidelines>
